fix: zero-init ML-DSA keygen DMA response#447
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot couldn't run its full agentic review because no GitHub Actions runner was available. Make sure your repository has a runner available to run Copilot's review, or add a copilot-setup-steps.yml file specifying one with the runs-on attribute. See the docs for more details.
This PR fixes an information-leak bug in the ML-DSA key generation DMA handler by ensuring the DMA response struct is deterministically initialized on all error paths.
Changes:
- Zero-initialize
whMessageCrypto_MlDsaKeyGenDmaResponse resin_HandleMlDsaKeyGenDmato prevent transmitting uninitialized stack bytes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Closing as redundant. In current |
Bug
In
_HandleMlDsaKeyGenDma(src/wh_server_crypto.c), the response struct is declared uninitialized:Multiple error paths return before
resis written —_IsMlDsaLevelSupportedfailure (WH_ERROR_BADARGS),wc_MlDsaKey_Init/SetParams/MakeKeyfailure, and DMA WRITE_PRE address-check failure beforeres.keyId/res.keySizeare set. All fall through towh_MessageCrypto_TranslateMlDsaKeyGenDmaResponsewith*outSize = sizeof(res), transmitting indeterminate stack bytes forres.keyId,res.keySize, andres.dmaAddrStatusto the client. (dmaAddrStatus.badAddris only set on WH_ERROR_ACCESS, so it is garbage for every other error.)Fix
Zero-initialize the response struct at declaration:
Error paths now transmit deterministic zeros instead of stack garbage. This matches the sibling DMA handlers, e.g.
_HandleAesCtrDmawhich doesmemset(&res, 0, sizeof(res))before any response send.Build verification
Compiled the translation unit against the standard wolfHSM server + ML-DSA + DMA config on Ubuntu 24.04:
Exit 0,
_HandleMlDsaKeyGenDmapresent as a defined text symbol.Reported by static analysis (Fenrir finding 463).
[fenrir-sweep:held]