CVE-2026-75900: Swtpm: swtpm: out-of-bounds read in swtpm_nvram_checkheader due to sizeof(pointer) vs sizeof(struct) mismatch
A flaw was found in swtpm. The SWTPMNVRAMCheckHeader() function in src/swtpm/swtpmnvstore.c validates the caller-supplied buffer length against sizeof(bh), where bh is a blobheader pointer. Because sizeof(bh) evaluates to the pointer size (8 bytes on 64-bit, 4 on 32-bit) rather than the struct size (10 bytes for the packed blobheader), an undersized buffer passes the entry guard. The subsequent access to bh->totlen at offset 6 reads 4 bytes, overreading the allocation by 2 bytes on 64-bit systems (6 bytes on 32-bit). On 64-bit systems with glibc, the overread typically hits allocator padding and the function returns an error without crashing. On 32-bit systems or with non-glibc allocators, daemon termination is possible, causing denial of service to the associated VM. In both cases, the out-of-bounds totlen value is logged, leaking a small amount of adjacent heap data. The control channel attack path requires no encryption keys. The fix is to change sizeof(bh) to sizeof(bh).
Other sources
An out-of-bounds read vulnerability was found in swtpm's SWTPMNVRAMCheckHeader() function. The entry guard checks the buffer length against sizeof(bh), where bh is a pointer, instead of sizeof(bh), the actual struct size. This allows an undersized buffer to pass validation, causing a 2-byte heap overread on 64-bit systems (6 bytes on 32-bit) when accessing the totlen field. This may cause daemon termination on some platforms and leaks heap data to the log.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed to denial of service?
The greatest denial-of-service risk is on 32-bit systems or systems using non-glibc allocators, where the out-of-bounds read can terminate the swtpm daemon and affect its associated VM. On 64-bit systems with glibc, the read typically reaches allocator padding and returns an error rather than crashing.
What access does an attacker need to trigger the issue?
An attacker needs local, low-privileged access and the ability to reach the swtpm control-channel attack path. No encryption keys are required for that path.
Can this disclose data even when it does not crash the daemon?
Yes. The out-of-bounds totlen value is logged, which can expose a small amount of adjacent heap data even when the function returns an error without crashing.
What code change fixes the vulnerable validation?
The length check must use sizeof(*bh) rather than sizeof(bh), so it validates against the packed blobheader structure size instead of the pointer size.