Live › vulnerability › CVE-2026-98728
Go to dashboardThe Linux kernel's TPM random-number path checks the response length against the wrong offset, so a truncated TPM response lets memcpy() read up to 4 bytes past the buffer end. The stale bytes end up in the random data handed to the caller.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with a TPM 2.0 chip whose driver calls tpm2_get_random(), where a malformed or truncated TPM response can occur. Impact is limited to information disclosure of kernel memory bytes in random output. Systems without a TPM or with an unaffected kernel can skip it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
tpm: fix off-by-four bounds check in tpm2_get_random()
When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random() skips the 4-byte parameter size field before locating the random data, but the bounds check still validates the response length against TPM_HEADER_SIZE. A truncated response can pass the check and make memcpy() read up to 4 bytes past the response end, so stale buffer contents end up in the caller's random bytes.
Fix this by checking the response length against 'offset', which already includes the skipped parameter size field.
This page as .md · .json · in your agent: get_signal("CVE-2026-98728")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.