Hi, On Wed, Sep 16, 2026 at 8:18 AM Fang Xieyan <[email protected]> wrote: > > gdb_cmd_query() decodes the hex payload of a qRcmd packet (the GDB > "monitor" command passthrough to kdb) into remcom_out_buffer and hands > it to kdb_parse(). It sizes the decode with strlen() of the payload: > > int len = strlen(remcom_in_buffer + 6); > ... > kgdb_hex2mem(remcom_in_buffer + 6, > remcom_out_buffer, len); > len = len / 2; > > kgdb_hex2mem() takes count as the number of bytes to produce and > decodes them in place at buf, reading and writing 2 * count bytes > there. len here is the hex character count, twice the decoded size, > so the decode runs over 2 * len bytes at remcom_in_buffer + 6, off > the end of the buffer. On x86 BUFMAX is 1024, so a 256-byte monitor > command (512 hex characters) overruns remcom_in_buffer during the > in-place decode: > > BUG: KASAN: global-out-of-bounds in kgdb_hex2mem+0x131/0x160 > Read of size 1 at addr ffffffff8765ef05 by task sh/1 > ... > kgdb_hex2mem+0x131/0x160 > gdb_serial_stub+0x16d4/0x3170 > kgdb_cpu_enter+0xb68/0x1520 > ... > The buggy address belongs to the variable: > remcom_in_buffer+0x405/0x420 > > Halve len before the call so kgdb_hex2mem() gets the decoded byte count. > It then reads the len hex characters already in remcom_in_buffer and > writes len / 2 bytes, all inside the buffer, and remcom_out_buffer holds > the same command as before. > > Fixes: a0de055cf613 ("kgdb: gdb "monitor" -> kdb passthrough") > Cc: [email protected] > Suggested-by: Douglas Anderson <[email protected]> > Link: > https://lore.kernel.org/all/CAD=FV=V1-gNZ8yTsC+D8inePWv=a+9h09hwjojqf5nrpcnv...@mail.gmail.com/ > Assisted-by: Qoder:Qwen3.8-Max > Signed-off-by: Fang Xieyan <[email protected]> > --- > > This is the third in a family of unvalidated-length decodes in the kgdb > gdbstub; the 'm' memread and 'M'/'X' memwrite fixes were sent separately. > Unlike those two, there is no attacker-claimed length field here. len is > the real hex-character count bounded by get_packet(), so the only defect > is passing the hex length instead of half of it to kgdb_hex2mem(). > Halving it is sufficient; no separate bounds check is needed. > > Reproducer: attach to a kgdboc console, break in, run kdb's "kgdb" > command to switch to gdb mode, then send a qRcmd packet with an even > hex payload of 510 or more characters, e.g. "qRcmd," + "41"*256 on x86. > Before the fix, KASAN reports a global-out-of-bounds read in > kgdb_hex2mem(): the decode runs to remcom_in_buffer+0x405, past > BUFMAX=0x400, and the guest dies. After the fix the decode stays > in-bounds, the command reaches kdb_parse() and the handler answers OK. > The patched run does print kdb_parse()'s own "command buffer overflow, > command ignored" for a 256-byte command; that is kdb's length limit on > the decoded string, not this bug. > > Tested on mainline 704340f1cd0d (git describe v7.3-rc3-9-g704340f1cd0d): > x86_64 defconfig plus CONFIG_KGDB_KDB and CONFIG_KASAN_GENERIC, gcc > 13.2.0, QEMU under TCG. Both kernels were built from byte-identical > .config files and differ only by this patch. > > kernel/debug/gdbstub.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Douglas Anderson <[email protected]> _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
