Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-08-19T08:17:14.073Z",
  "pubdate": "2026-08-19T08:17:14.073Z",
  "executiveSummary": "An out-of-bounds read vulnerability has been identified in the swtpm software package, specifically within the SWTPM_NVRAM_CheckHeader() function. This security defect arises due to an incorrect size validation check where the buffer length is compared against the size of a pointer variable rather than the actual referenced structure. Consequently, an undersized buffer bypasses the entry guard validation checks.\nThe primary impact of this vulnerability includes unauthorized heap data disclosure, where internal heap memory contents are leaked into log files, and potential application crashes leading to denial of service through daemon termination on architectures where memory access violations are strictly enforced. The affected system is swtpm, impacting environments utilizing the NVRAM state handling routines.\nExploitation of this vulnerability involves supplying a malformed or undersized NVRAM header buffer to the vulnerable function. An attacker capable of influencing or providing the NVRAM state data processed by the daemon can trigger the flaw. The vulnerability requires local or input-delivery access depending on how the swtpm instance ingests untrusted NVRAM state data, resulting in an information leak and potential service availability disruption without requiring advanced authentication or high privileges.",
  "technicalDetails": "The vulnerability resides in the SWTPM_NVRAM_CheckHeader() function of swtpm, which is responsible for validating NVRAM state headers during initialization or state loading operations. The root cause of the vulnerability is a programming logic error in the entry guard boundary validation. Specifically, the function checks the incoming buffer length against sizeof(bh), where bh is defined as a pointer to the header structure, rather than utilizing sizeof(*bh) to evaluate the actual memory footprint of the underlying struct type.\nBecause the size of a pointer on 64-bit systems is 8 bytes (and 4 bytes on 32-bit systems), whereas the actual header structure bh requires a larger size to encompass all expected fields including the totlen field, the validation check incorrectly permits buffers that are smaller than the required structure size to pass the safety check.\nThe step-wise attack flow proceeds as follows: First, an attacker supplies an engineered NVRAM state file or payload containing an undersized header that satisfies the erroneous pointer-size check but is smaller than the actual structure definition. Second, SWTPM_NVRAM_CheckHeader() accepts the undersized buffer and proceeds to parse the data structure. Third, when the execution reaches the point of accessing the totlen field within the header structure, the code reads past the boundaries of the allocated buffer due to the insufficient length. On 64-bit systems, this results in a 2-byte heap overread (and a 6-byte heap overread on 32-bit systems).\nThe payload behavior and post-exploitation impact manifest in two ways. The out-of-bounds read accesses adjacent heap memory, capturing raw trailing heap bytes. Depending on platform-specific memory protection mechanisms and runtime behavior, attempting to read unmapped or restricted memory past the buffer allocation causes a segmentation fault or memory access exception, terminating the swtpm daemon and resulting in a denial of service. Furthermore, if the adjacent heap data is processed or printed during error handling or logging, the contents of the adjacent heap memory are leaked into the system logs, potentially exposing sensitive data residing in the heap to unauthorized observers."
}