CVE-2026-123151: Gdb: gdb: stack buffer overflow in parse_tsv_definition via stale rs->buf tail
A flaw was found in the GNU debugger (GDB). When GDB connects to a remote debug target, a malicious target can cause GDB to overflow a buffer on the stack while parsing the target's replies. This can crash GDB or potentially allow the target to execute arbitrary code in the GDB client process with the privileges of the user running GDB.
Other sources
Stack buffer overflow in parsetsvdefinition (gdb/tracepoint.c), called from remotetarget::uploadtracestatevariables during startremote1, before the ? packet. The parser sizes its destination with alloca(strlen(line)) based on the current qTfV trace-state-variable reply, then advances through three colon-separated fields with unchecked p++. A line such as 1:0:0000 contains only two colons, so the third p++ walks past the line's terminating NUL into stale bytes of the shared, uncleared packet buffer rs->buf (planted, for example, by a long qTStatus reply, which must be answered non-empty for the upload to run at all). hex2bin then decodes strlen(p)/2 stale bytes -- whose length and content the stub controls -- into the small stack buffer, overwriting the stack canary and the return address. This is the same stale-tail pattern as CVE-2026-121995 (parsetracepointdefinition), in the sibling parser for trace state variables; the function, call site and fix location differ. Verified on gdb-16.3-3.1.el102 (Rocky 10.2): ' stack smashing detected ' abort 5/5 runs with a symbolized stack stackchkfail <- parsetsvdefinition (tracepoint.c) <- uploadtracestatevariables <- startremote1 <- open1, and an ASan rebuild of the distro source reports dynamic-stack-buffer-overflow in hex2bin <- parsetsvdefinition. Negative controls (short stale tail; well-formed three-colon line) do not crash. Present and unfixed in upstream master (f735688fc, 2026-11-05); the same code exists at least back to the GDB 10.2 release tree. Reported by Pulkit Singh Singaria (x3ero0) via PSIRTSUPT-29860.
— Red Hat