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

From: Doug Anderson

Date: Mon Sep 14 2026 - 20:21:06 EST


Hi,

On Mon, Sep 14, 2026 at 11:04 AM Fang Xieyan <fangxy@xxxxxxxxxxxx> wrote:
>
> gdb_cmd_memread() passes the length of the 'm' packet straight to
> kgdb_mem2hex(), which hex-encodes the reply into
> remcom_out_buffer[BUFMAX] without checking that the reply fits. A
> client on the KGDB I/O console can ask for a read of any size, and
> the hex encoding runs off the end of the buffer. kgdb_mem2hex() takes
> that length as an int count, so 2^31 truncates to a negative value
> and copy_from_kernel_nofault() is handed buf + count as its
> destination.
>
> On x86 BUFMAX is 1024, so a read of 512 bytes overruns by the single
> byte that terminates the hex string:
>
> BUG: KASAN: global-out-of-bounds in kgdb_mem2hex+0x1dd/0x230
> Write of size 1 at addr ffffffff87651780 by task sh/1
> ...
> The buggy address belongs to the variable:
> remcom_out_buffer+0x400/0x420
>
> Bounds check the length before the hex encoding:
>
> if (length > (BUFMAX - 1) / 2) {
> error_packet(remcom_out_buffer, -EINVAL);
> return;
> }
>
> gdbstub_msg_write() already bounds the count it hex-encodes
> against BUFMAX. Reads over the limit never returned valid data,
> so an error reply loses nothing.
>
> Fixes: dc7d55270521 ("kgdb: core")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: Hawkeye:GLM-5.3-flash
> Assisted-by: Qoder:Qwen3.8-Max
> Signed-off-by: Fang Xieyan <fangxy@xxxxxxxxxxxx>

Looks like a good fix to me.

Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>


> The scanner is a taint-style review of the packet handlers in
> kernel/debug/gdbstub.c. write_mem_msg() ('M' and 'X' packets) trusts
> the same length field and looks like the same class of problem; I can
> send that separately if there is interest.

Yeah, my AI also says 'M' and 'X' packets likely have the same bug. It
also claims qRcmd packet may have similar issues. Sending a patch to
fix would be great.

-Doug