Re: [PATCH v3] USB: serial: garmin_gps: fix signed integer underflow and OOB read on packet length

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Sep 19, 2026 at 11:28:18AM +0000, Hui Peng wrote:
> getDataLength() returns a signed int from __le32_to_cpup((__le32
> *)(garmin_data_p + 8)). When bit 31 is set (e.g. 0x80000004), len is
> negative (-2147483644), bypassing the upper bound check (GSP_INITIAL_OFFSET
> + len > GSP_MAX_BUFSIZ) in gsp_send() and triggering a KASAN slab-out-of-
> bounds read in garmin_write_bulk() when GARMIN_PKTHDR_LENGTH + len wraps
> around to 16.
> 
> Kernel stack trace:
> BUG: KASAN: slab-out-of-bounds in garmin_write_bulk+0x164/0x3b0
> Read of size 16 at addr ffff88800791400c by task poc_verify/188
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x4d/0x70
>  print_report+0xc4/0x610
>  kasan_report+0xb8/0xf0
>  kasan_check_range+0x118/0x190
>  memcpy+0x24/0x60
>  garmin_write_bulk+0x164/0x3b0
>  gsp_send+0x218/0x490
>  garmin_write+0x142/0x2c0
>  tty_write+0x294/0x540
>  vfs_write+0x412/0x640
>  </TASK>
> 
> 
> Note that garmin_write_bulk() and garmin_write_bulk_callback() are
> triggered from local userspace calling write(fd, ...) on /dev/ttyUSB0
> (even with a normal USB device attached) by writing a 12-byte packet
> with a negative 32-bit length field (e.g. 0x80ffffff) at byte offset 4.
> 
> Kernel stack trace (Linux 7.3.0-rc3):
>  ==================================================================
>  BUG: KASAN: slab-out-of-bounds in garmin_write_bulk+0x922/0xbf0
>  Read of size 12 at addr ffff88800f8ef958 by task usb_poc_verify/162
>  Call Trace:
>   <TASK>
>   dump_stack_lvl+0x70/0xa0
>   print_report+0x153/0x4c6
>   kasan_report+0xf1/0x120
>   kasan_check_range+0x11c/0x200
>   __asan_memcpy+0x29/0x70
>   garmin_write_bulk+0x922/0xbf0
>   garmin_write+0x3e6/0x770
>   serial_write+0x167/0x2b0
>   n_tty_write+0x5f4/0x1020
>   file_tty_write.isra.0+0x411/0x760
>   vfs_write+0x671/0xd20
>   ksys_write+0x1bb/0x210
>   do_syscall_64+0xda/0x4b0
>   </TASK>
>  ==================================================================
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Assisted-by: LLM
> Signed-off-by: Hui Peng <benquike@gmail.com>
> ---
> v3: Add a Fixes: tag and use the conventional subject prefix.
> 
> The length arithmetic in gsp_send() and nat_receive() is unchanged
> since the initial git import - garmin_gps.c is already present in
> 1da177e4c3f4 with the same signed getDataLength() and the same missing
> bound - so that is the tag. The later commits git blame surfaces are
> not introducers: af6d780b5787 ("garmin_gps: Coding style") and
> fb571101af63 ("USB: serial: fix compare_const_fl.cocci warnings") are
> cosmetic, and b4072f46e57f only re-nested an existing condition.
> 
> Greg asked on an earlier posting whether this is an untrusted-device
> issue or something a local user can trigger. To be explicit: hunks 1
> and 2 are reached from userspace. gsp_send() consumes the buffer that
> write() fills via garmin_write(), so a local user with access to
> /dev/ttyUSBn can drive the length arithmetic directly without any
> malicious hardware. Hunk 3 is the device-input side and is plain
> hardening in the sense of
> Documentation/process/threat-model.rst - we trust the device, and I am
> not claiming otherwise.

So as this patch is doing multiple things, please split it into multiple
patches, like our documentation asks your LLM to do :)

thanks,

greg k-h