A flaw was found in the GDB STABS debug format parser. The
read_member_functions() function in gdb/stabsread.c processes C++ member
function lists from STABS symbol data. When a class contains both
destructor and non-destructor member functions, the code at lines
5086-5131 attempts to separate them into two lists. However, the linked
list removal logic has a bug: the `last_sublist` tracking variable is
updated to point to REMOVED destructor nodes instead of the previous
retained node, and the `continue` path for non-destructor nodes does not
update `last_sublist` at all. This causes destructor entries to remain
in the `sublist` linked list while the `length` variable is decremented
by `has_destructor`. In the subsequent copy loop (lines 5163-5166), the
allocated array has `length` elements but the loop iterates over all
remaining `sublist` entries (more than `length`). The loop index `i`
starts at `length` and decrements, going negative, causing writes before
the allocated obstack array. The written data consists of `struct fn_field`
members controlled by the attacker through crafted STABS strings. The
obstack underflow can corrupt chunk metadata including function pointers,
which are called on subsequent obstack operations, resulting in arbitrary
code execution. The vulnerability triggers automatically when GDB expands
partial symbol tables — any symbol-inspection command (break, ptype, info
functions) on a binary containing crafted .stab/.stabstr sections is
sufficient. The inferior process does not need to be executed.

    Upstream: https://sourceware.org/git/binutils-gdb.git
    Affected: gdb/stabsread.c (read_member_functions, lines 5086-5166)
    Confirmed on: GDB 16.3-1, Debian trixie, x86-64, glibc 2.41
    Reporter: JD Marsters (Bhut Red)