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.