CVE-2026-98728

What it actually does

The vulnerability allows a malformed TPM2 response carrying the TPM2_ST_SESSIONS tag to bypass the bounds check in tpm2_get_random() because the check still validates only against TPM_HEADER_SIZE instead of the full offset; this permits memcpy to read up to 4 bytes past the response buffer, returning stale kernel memory contents as random data to the caller.

Why it matters to the business

Systems relying on the TPM for cryptographic randomness may receive predictable or leaked memory values instead of secure random bytes, weakening key generation, session tokens, and other security primitives that depend on high-quality entropy from the kernel.

How an attack unfolds

An attacker who can influence or emulate the TPM response path supplies a truncated response that includes the TPM2_ST_SESSIONS tag; tpm2_get_random skips the 4-byte parameter size field yet still passes the insufficient length check, allowing the subsequent memcpy to copy data from beyond the allocated buffer and deliver uninitialized memory to callers requesting random bytes.

How to fix it

Apply the upstream kernel patch that changes the bounds check in tpm2_get_random to validate against the computed 'offset' value which already accounts for the skipped parameter size field; rebuild and deploy the corrected kernel on all affected systems.

How to confirm the fix worked

Review the tpm2_get_random function to confirm the length check now uses 'offset' rather than TPM_HEADER_SIZE; if feasible, exercise the function with deliberately truncated TPM2_ST_SESSIONS responses and verify that out-of-bounds reads are rejected.

Typical attack path

1. Gain control over the TPM response channel via compromised firmware, emulated device, or malicious hardware
2. Craft a truncated response containing the TPM2_ST_SESSIONS tag but lacking sufficient payload length
3. Trigger a call path that invokes tpm2_get_random from kernel or user-space code
4. Observe or capture the returned buffer containing up to 4 bytes of stale kernel memory

How to detect it

Search kernel logs and TPM driver traces for unusual response lengths or error paths around tpm2_get_random; examine any code that directly invokes the TPM random-number interface for signs of unexpected data patterns in returned buffers.

What your security team should do

• Expedite kernel updates on any system that uses the in-kernel TPM driver for randomness generation
• Audit applications and libraries that obtain entropy via the kernel TPM interface
• Temporarily favor alternative entropy sources such as hardware RNGs or CPU instructions when TPM response integrity cannot be assured