Check RNG response length before copying inline payload

[yosuke-wolfssl]

Problem

wh_Client_RngGenerateResponse validated the server-reported size against the inline cap (WH_MESSAGE_CRYPTO_RNG_MAX_INLINE_SZ) and the caller's buffer, but never against res_len — the length of the frame actually received. A truncated or malformed OK response could set sz past what the frame delivered, making the client memcpy stale comm-buffer bytes and hand them back as random data. Every other inline-copy handler in wh_client_crypto.c (AES-CTR/ECB/CBC/GCM, ECC, Curve25519, Ed25519, RSA, CMAC) already performed this check; RNG was the last one missing it.

The DMA variant copies nothing inline, so it had no read exposure, but it equally never confirmed that a success reply was backed by a full response frame.

Fix (src/wh_client_crypto.c)

• wh_Client_RngGenerateResponse derives hdr_sz from the generic response header plus whMessageCrypto_RngResponse and rejects when res_len < hdr_sz || res->sz > (res_len - hdr_sz). The first term also prevents the unsigned underflow in the second.
• wh_Client_RngGenerateDmaResponse rejects a success reply whose frame is shorter than that same header pair. This is defense in depth, not an out-of-bounds fix: no field of the DMA response is read inline today, so the check pins the frame to the protocol contract for future readers. Error replies legitimately carry only the generic header and are unaffected, since the check sits behind the rc gate.

Addressed by f_5460. This PR is now source-only.

Tests

The test added by the earlier revision has been removed. It was
test-refactor/misc/wh_test_client_malformed_resp.c (319 lines), which paired a
real client with a raw whCommServer so it could emit frames a real server never
emits. Per review, a test reachable only through a fake transport or a hand-built
packet is testing the harness, not the fix, so it and its wh_test_list.c entry
are dropped. This also removes the add/add conflict with #473/#474/#475/#476,
which each created the same file.

No replacement test is added here: the guard rejects a frame shape the normal
wh_Client_* API cannot produce against a conforming server, so there is no
client-driven case that reaches it.

Verification

• test-refactor: default 37 passed / 25 skipped / 0 failed of 62 · DMA=1 41/21/0 · SHE=1 43/19/0
• Legacy test/ suite clean.
• Clean under -std=c90 -Werror -Wall -Wextra.
• The guard itself was previously negative-controlled: removing only
  res_len < hdr_sz || lets the short-frame case through, since the subtraction
  underflows and the copy proceeds.

[Copilot]

Pull request overview

Hardens the client-side RNG response handler against truncated/malformed server frames by validating that the received response length actually contains the claimed inline payload, preventing out-of-bounds reads of stale comm-buffer data.

Changes:

• Add a response-frame-length bound check in wh_Client_RngGenerateResponse before copying inline RNG payload.
• Add a new misc test that crafts malformed RNG responses over the mem transport to verify the abort behavior and that caller output remains untouched.
• Register the new test in the refactored test list.

Reviewed changes

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

File	Description
src/wh_client_crypto.c	Adds res_len vs header/payload size validation before inline RNG payload memcpy.
test-refactor/misc/wh_test_client_malformed_resp.c	New regression test that sends truncated RNG responses and asserts WH_ERROR_ABORTED + no buffer clobber.
test-refactor/wh_test_list.c	Registers whTest_ClientMalformedResp in misc tests.

---

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

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #463

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

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

[bigbrett]

We don't need regression tests for every single argument validation scenario, especially when it requires setting up and tearing down an entire harness just to check something like this. We are going to start bogging down our test framework. Please remove this test for now.