CVE-2026-75900 in Red Hat
Summary
by MITRE • 08/19/2026
An out-of-bounds read vulnerability was found in swtpm's SWTPM_NVRAM_CheckHeader() 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in the swtpm project, specifically within the SWTPM_NVRAM_CheckHeader function, represents a critical logic error rooted in incorrect pointer arithmetic during buffer validation. The core technical flaw lies in how the entry guard evaluates the size of the binary header structure bh. Instead of checking if the provided buffer length is sufficient to contain the actual data structure by using sizeof(*bh), which correctly calculates the byte size of the struct that bh points to, the code erroneously uses sizeof(bh). Since bh is a pointer variable, this expression returns the memory address size required to store the pointer itself rather than the payload it references. On 64-bit systems where pointers occupy eight bytes, and on 32-bit systems where they occupy four bytes, this check fails to enforce the minimum structural requirements of the NVRAM header. Consequently, a buffer that is significantly smaller than the actual struct definition can pass validation without triggering an error condition.
This misconfiguration leads directly to an out-of-bounds read vulnerability when the application proceeds to access fields within the header structure. Specifically, after passing the flawed size check, the code attempts to read the totlen field from the buffer. Because the input buffer was validated against a smaller pointer-sized value rather than the full struct size, it lacks the necessary data at the expected offset for this field. On 64-bit architectures, this results in reading two bytes beyond the allocated heap memory boundary, while on 32-bit systems, the overread extends by six bytes. This operation constitutes an out-of-bounds read that violates standard memory safety principles and exposes internal application state to external observation or manipulation depending on how subsequent code handles the retrieved data.
The operational impact of this vulnerability is twofold, affecting both system stability and information security. In many execution environments, accessing invalid heap memory triggers a segmentation fault or similar protection mechanism enforced by the operating system, leading to immediate daemon termination. This results in a denial-of-service condition for services relying on swtpm for virtualized trusted platform module operations. Furthermore, even if the process does not crash immediately due to specific compiler optimizations or runtime protections being absent, the overread operation leaks heap data into log files or other output channels. This information disclosure can reveal sensitive internal states, such as pointers to other objects in memory, cryptographic keys stored nearby on the heap, or sequence numbers that could aid attackers in crafting more sophisticated exploits targeting adjacent memory regions.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read, which describes reading data from outside of intended boundaries due to improper validation of input sizes. The attack vector typically involves an attacker providing crafted NVRAM image files or configuration inputs that trigger the header parsing routine within swtpm. In terms of adversary tactics, this flaw facilitates reconnaissance and potentially privilege escalation if combined with other vulnerabilities, fitting into ATT&CK techniques related to Collection via Local File Access or Discovery through Memory Dumping depending on how the leaked data is utilized by an attacker who has gained initial access to the system running the vulnerable service.
Mitigation strategies must prioritize immediate patching of the source code to correct the sizeof operator usage in SWTPM_NVRAM_CheckHeader(). The fix requires replacing sizeof(bh) with sizeof(*bh) or explicitly defining the expected header size constant to ensure strict adherence to structural memory requirements. Additionally, developers should implement robust bounds checking that validates not only the initial buffer length but also ensures all subsequent field accesses remain within the validated limits. For system administrators unable to patch immediately, restricting file upload capabilities and limiting log verbosity for NVRAM operations can reduce exposure of leaked heap data. Regular security audits focusing on pointer arithmetic and size validation in C/C++ codebases are essential to prevent similar logic errors that undermine memory safety guarantees.