This series mirrors the two gs_usb hardening fixes that landed in 6.18
(commits 6fe9f3279f7d and 395d988f9386) for the two PEAK-System USB
drivers that share the same "walk records inside the bulk-in URB"
pattern: pcan_usb_fd.c and pcan_usb_pro.c. Both decode loops read the
on-wire record header before validating that the URB actually contains
that header, allowing a malicious USB device that emulates a PEAK CAN
adapter to trigger a short read of one or two bytes past the URB
buffer on every poll cycle.

Patch 1 adds a sizeof(struct pucan_msg) check at the top of the
pcan_usb_fd_decode_buf() loop and rejects records whose announced size
is smaller than the header itself.

Patch 2 adds a one-byte check before reading pr->data_type in
pcan_usb_pro_decode_buf(), which is the field used to index the
record-size table.

Both fixes are static-analysis-identified mirrors of the gs_usb
precedent. I did not have access to a PCAN-USB-FD or PCAN-USB-Pro
adapter and therefore no live KASAN trip is attached, but the trigger
condition (URB actual_length below the per-record header size) is
identical to the gs_usb case that Marc Kleine-Budde fixed in November.

A third candidate file, drivers/net/can/usb/usb_8dev.c, was reviewed
for the same pattern but already validates "pos + sizeof(struct
usb_8dev_rx_msg) > urb->actual_length" at the top of its loop and uses
a fixed-size record, so no patch is included for it.

Note: a concurrent series by James Gao (msgid <TYCPR01MB856782BAA657447E5EDDDC1FF0062>) hardens different sites in pcan_usb_pro.c (handle_canmsg + handle_error); the hunks in patch 2/2 here do not overlap.

Berkant Koc (2):
  can: peak_usb: validate URB length in pcan_usb_fd_decode_buf()
  can: peak_usb: validate URB length in pcan_usb_pro_decode_buf()

 drivers/net/can/usb/peak_usb/pcan_usb_fd.c  |  7 ++++---
 drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 15 +++++++++++++--
 2 files changed, 17 insertions(+), 5 deletions(-)

-- 
2.47.3