REDHAT-BUG-2567333: Buffer Overflow

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.