Description

A flaw was found in GDB's STABS debug format parser. The read_member_functions() function in gdb/stabsread.c contains a linked list removal bug in the code that separates destructor and non-destructor member functions of C++ classes. The bug causes the destructor entries to remain in the main function list while the list length counter is decremented, resulting in an out-of-bounds write when the function list is copied to its final allocated array. An attacker can craft an ELF binary with malicious .stab and .stabstr sections that triggers this out-of-bounds write when a user opens the file in GDB and performs any symbol-inspection operation such as setting a breakpoint. The inferior process does not need to be executed. Under controlled conditions, this was demonstrated to achieve execution of arbitrary commands within the GDB process.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-31T20:17:02.180Z",
  "pubdate": "2026-08-31T20:17:02.180Z",
  "executiveSummary": "A critical memory corruption vulnerability exists within GDB's STABS debug format parser, specifically located in the read_member_functions() function within gdb/stabsread.c. The flaw manifests as an out-of-bounds (OOB) write originating from an improper linked list manipulation during the categorization of C++ member functions.\nBy crafting a malicious ELF binary containing specifically structured .stab and .stabstr sections, an attacker can trigger this OOB write when a user performs symbol-inspection operations, such as setting a breakpoint or loading the binary, without requiring the execution of the inferior process.\nSuccessful exploitation allows for arbitrary code execution within the GDB process context, granting an attacker the same privileges as the user running GDB. The vulnerability poses a significant risk to developers and security analysts who may unknowingly process malicious debug information. There are no authentication or network requirements for exploitation, as the vector is triggered locally upon loading a crafted file.\nThis issue highlights the dangers inherent in parsing complex, legacy debug formats and the critical need for input validation when handling untrusted ELF debugging metadata.",
  "technicalDetails": "The vulnerability resides in the read_member_functions() function within gdb/stabsread.c, responsible for parsing C++ class member functions from the STABS debug format. The root cause is a logic error in the linked list management used to separate destructor functions from non-destructor member functions.\nDuring the parsing process, when a destructor is identified, the algorithm attempts to remove it from the main member function linked list. However, the implementation fails to correctly manage the list pointers, causing the destructor entries to remain physically linked in the main list while the internal list length counter is decremented. This discrepancy between the actual list structure and the counter creates a state where the metadata tracking the number of elements is inconsistent with the allocated memory structure.\nThe exploitation flow initiates when GDB parses the malformed .stab and .stabstr sections of a specially crafted ELF file. When the function list is subsequently copied to its final heap-allocated array, the loop responsible for the copy operation relies on the corrupted counter. Because the counter does not account for the 'ghost' destructor entries still present in the list, the copy operation performs an out-of-bounds write beyond the bounds of the destination buffer.\nAn attacker can leverage this primitive to overwrite adjacent heap metadata or function pointers stored in the heap. By carefully controlling the content of the .stab sections, the attacker influences the data being written during the OOB operation. If a function pointer is successfully overwritten, the attacker can redirect the control flow of GDB when the application later executes the corrupted pointer during routine symbol inspection or breakpoint handling.\nThis vulnerability does not require the target binary to be executed; the malicious payload is triggered automatically upon loading the file and initiating symbol inspection, such as by running 'gdb <malicious_binary>' and issuing a 'break' command. The impact is complete compromise of the GDB process, allowing for arbitrary command execution under the user's security context. The flaw is inherent to the parser logic and affects any GDB version utilizing this specific implementation of the STABS parsing routine."
}