Bound KDF response output size against received frame

[yosuke-wolfssl]

Problem

_HkdfMakeKey and _CmacKdfMakeKey copied res->outSz bytes out of the comm
buffer after checking the declared size only against the caller's output
buffer. Neither used res_len, the number of bytes actually received, so a
malformed or compromised server response could declare more output than the
frame carried. The client would then read past the end of the received
response and hand the caller data that was never derived key material. Every
other variable-length response handler in wh_client_crypto.c already
performs this check (wh_Client_EccSignResponse, _EccSharedSecretResponse,
wh_Client_AesGcmResponse, wh_Client_MlKemDecapsulate, and others).

With a conforming server the server-side outSz > max_size guard prevents
this, so the impact is confined to malformed or compromised server responses,
matching the threat model of the other findings in this class.

Addressed by f_6201.

Changes:

• Validate res->outSz against the received frame length in _HkdfMakeKey
  and _CmacKdfMakeKey, before the response is consumed. Matches the existing
  hdr_sz idiom used by the other response handlers in this file.
• Apply the check unconditionally rather than only on the export path. The
  cache path reports outSz == 0, so a conforming response passes either way,
  and a truncated frame is malformed regardless of whether the caller asked
  for output.
• New test-refactor/misc/wh_test_client_respbounds.c, registered in
  wh_test_list.c under the misc group. A stub client transport stands in for
  the server with no server process, echoing the request header and replying
  with a frame that overstates the output size. Both KDF helpers are driven
  through two malformed shapes: a full response header carrying no key
  material, and a frame too short to hold the response header at all. Each
  case asserts WH_ERROR_ABORTED and that the caller's buffer was left
  untouched.

Verification:

• Both branches of the new guard were confirmed by negative control. Before
  the fix the client returned WH_ERROR_OK and copied 256 bytes of adjacent
  comm-buffer contents into the caller's key buffer. With only the second
  half of the guard the short-frame case still slipped through, since
  res_len - hdr_sz underflows when res_len is smaller.
• test-refactor suite: 38 passed, 0 failed. Legacy test suite clean.

[Copilot]

Pull request overview

This PR hardens the client-side KDF response handling in wh_client_crypto.c by validating the declared output size (res->outSz) against the actual received frame length (res_len), preventing reads past the end of the received response when dealing with malformed or compromised server replies.

Changes:

• Add defensive res_len-based bounds checks in _HkdfMakeKey and _CmacKdfMakeKey before consuming/copying response output.
• Apply the bounds check unconditionally (including cache/no-export paths).
• Add a new test-refactor misc test that simulates truncated/overstated responses via a stub transport and asserts WH_ERROR_ABORTED + unchanged caller output buffer.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
test-refactor/wh_test_list.c	Registers the new misc test in the refactored test suite.
test-refactor/misc/wh_test_client_respbounds.c	Adds a stub-transport regression test covering overstated outSz and truncated-frame cases for HKDF/CMAC-KDF.
src/wh_client_crypto.c	Enforces res->outSz ≤ bytes actually received (after headers) for HKDF/CMAC-KDF responses.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #467

Scan targets checked: wolfhsm-crypto-bugs, wolfhsm-src

No new issues found in the changed files. ✅