Bug 2567333 (CVE-2026-123151)

Summary: CVE-2026-123151 gdb: gdb: stack buffer overflow in parse_tsv_definition via stale rs->buf tail
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-11-05 14:59:37 UTC 
Stack buffer overflow in parse_tsv_definition (gdb/tracepoint.c), called from remote_target::upload_trace_state_variables during start_remote_1, 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 (parse_tracepoint_definition), in the sibling parser for trace state variables; the function, call site and fix location differ. Verified on gdb-16.3-3.1.el10_2 (Rocky 10.2): '*** stack smashing detected ***' abort 5/5 runs with a symbolized stack __stack_chk_fail <- parse_tsv_definition (tracepoint.c) <- upload_trace_state_variables <- start_remote_1 <- open_1, and an ASan rebuild of the distro source reports dynamic-stack-buffer-overflow in hex2bin <- parse_tsv_definition. 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.