Hello, On 23/07/2026 at 16:01:27 +02, shj <[email protected]> wrote:
> 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: shj <[email protected]> Thanks for the contribution. Unfortunately, this is not a proper SoB line, you must put your real identity there. With this fixed, I am fine with the approach, Acked-by: Miquel Raynal <[email protected]> Thanks, Miquèl
