CVE-2026-116732 in libdwarf
Summary
by MITRE • 10/26/2026
libdwarf through 2.3.3 contains a heap out-of-bounds read vulnerability in dwarf_debug_addr_table() that omits the table starting offset when validating .debug_addr unit length. Attackers can supply a crafted object file with a non-zero offset table, causing dwarf_debug_addr_by_index() to read past the heap buffer, disclosing adjacent heap bytes or crashing consumers.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in libdwarf versions through 2.3.3 represents a critical memory safety flaw within the DWARF debugging information parsing logic. Specifically, the defect resides in the dwarf_debug_addr_table function which is responsible for processing .debug_addr sections found in compiled object files and executables. The .debug_addr section was introduced to optimize debug info by storing address ranges separately from line number tables, allowing multiple compilation units to share common address range data. However, the implementation fails to correctly account for the table starting offset when validating the length of this unit. This oversight creates a scenario where the bounds checking logic does not properly align with the actual memory layout expected during parsing operations that follow.
From a technical perspective, the core issue is an off-by-one or similar boundary calculation error in how the library calculates valid read limits for heap-allocated buffers containing debug address data. When dwarf_debug_addr_by_index is invoked to retrieve specific entries from this table, it relies on calculations derived from the initial validation step. Because the starting offset was omitted during that validation phase, the subsequent index-based access logic miscalculates the upper bound of the accessible memory region. Consequently, if an attacker provides a crafted object file containing a non-zero offset in its debug address table structure, the library will attempt to read beyond the allocated heap buffer boundaries. This constitutes a classic out-of-bounds read vulnerability where the application accesses memory locations that it does not own or should not access according to standard security models.
The operational impact of this flaw is significant for any software that utilizes libdwarf to parse DWARF data, particularly debuggers, profilers, and crash analysis tools. An attacker who can supply a maliciously crafted object file containing the specific malformed .debug_addr section can trigger this vulnerability during normal parsing operations. The immediate consequence is an out-of-bounds read which may lead to two primary outcomes depending on the surrounding heap layout and memory state. First, it can result in a denial of service by causing the consuming application to crash due to accessing invalid or protected memory pages. Second, and more critically, if the adjacent heap bytes contain sensitive information such as pointers, credentials, or other internal data structures, this vulnerability enables an information disclosure attack where private memory contents are leaked back to the attacker through the program's output or error handling mechanisms.
This type of vulnerability aligns with Common Weakness Enumeration standard CWE-125 which describes out-of-bounds read conditions that allow attackers to access unintended memory regions. In terms of offensive security frameworks, this behavior maps closely to ATT&CK technique T1083 known as File and Directory Discovery or potentially T1005 Data from Local System depending on the specific data exfiltrated, although it is primarily a precursor capability for more advanced exploitation chains such as heap spraying or further memory corruption attacks. The lack of proper boundary validation in parsing untrusted input like compiled binaries highlights a failure to implement robust defensive coding practices regarding buffer length checks relative to actual offsets provided by external sources.
Mitigation strategies must focus on immediate patching and long-term architectural improvements. Users should upgrade libdwarf to version 2.3.4 or later where this specific validation logic has been corrected to properly include the table starting offset in its boundary calculations. For organizations unable to immediately update, implementing input sanitization at the application layer that validates DWARF section lengths before passing them to the library can provide a temporary buffer against exploitation. Furthermore, developers integrating libdwarf should consider enabling Address Sanitizer during testing phases to detect such memory errors early in the development lifecycle. Regular security audits of third-party dependency code are essential to identify similar parsing flaws where external data structures dictate internal memory access patterns without sufficient verification of their integrity and bounds.