A TPM reply's length is taken from the device and only upper-capped, then several callers use it unchecked: the TPM1 OIAP helpers and the TPM2 GetCapability parser subtract a fixed header length from it, so a reply too short underflows the subtraction into a huge memcpy; the GetCapability parser then copies that many bytes into the caller's buffer, so a reply longer than the buffer overruns it. Because a TPM sits on a physically accessible bus, a cheap bus interposer (the kind used to sniff disk-encryption keys) can inject such a reply, and on the TPM2 path this parsing runs during measured boot, which is exactly the physical attacker that measured boot is meant to resist.
Patch 1 bounds the reported length against the header and, for a properties query, the caller's buffer. Patch 2 adds regression tests driving the TPM2 parser with a truncated and an over-long reply through the sandbox emulator. Based on v2026.07 (fdfe2ec48d5c). A reproducer is available on request. Signed-off-by: Shahriyar Jalayeri <[email protected]> --- Changes in v2: - Use my real name in the From and Signed-off-by (Miquel Raynal) --- Shahriyar Jalayeri (2): tpm: bounds-check the device-controlled response length test: tpm: check malformed capability responses are rejected drivers/tpm/tpm2_tis_sandbox.c | 27 +++++++++++++++++++++++++++ include/tpm-v2.h | 10 ++++++++++ lib/tpm-v1.c | 6 ++++++ lib/tpm-v2.c | 8 ++++++++ test/dm/tpm.c | 41 +++++++++++++++++++++++++++++++++++++++++ 5 files changed, 92 insertions(+) --- base-commit: fdfe2ec48d5c1c2ed03073d73edd3fdd3fe1ffa1 change-id: 20260723-tpm-trunc-resp-664a3babf1cf Best regards, -- Shahriyar Jalayeri <[email protected]>
