Re: [PATCH] kgdb: Fix buffer overflow in the qRcmd packet handler

[Doug Anderson]

Hi,

On Wed, Sep 16, 2026 at 8:18 AM Fang Xieyan <fangxy@xxxxxxxxxxxx> 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: stable@xxxxxxxxxxxxxxx
> Suggested-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> Link: https://lore.kernel.org/all/CAD=FV=V1-gNZ8yTsC+D8inePWv=A+9H09hWJojQf5NRpcNvK+Q@xxxxxxxxxxxxxx/
> Assisted-by: Qoder:Qwen3.8-Max
> Signed-off-by: Fang Xieyan <fangxy@xxxxxxxxxxxx>
> ---
>
> 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 <dianders@xxxxxxxxxxxx>