From: Berkant Koc <me@berkoc.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Vincent Mailhol <mailhol@kernel.org>,
Stephane Grosjean <stephane.grosjean@hms-networks.com>
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: [PATCH 0/2] can: usb: validate URB length in PEAK-USB rx callbacks
Date: Sun, 17 May 2026 15:55:00 +0200 [thread overview]
Message-ID: <20260517-can-usb-fix-cover@berkoc.com> (raw)
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
next reply other threads:[~2026-05-17 14:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 13:55 Berkant Koc [this message]
2026-05-17 13:55 ` [PATCH 1/2] can: peak_usb: validate URB length in pcan_usb_fd_decode_buf() Berkant Koc
2026-05-17 17:26 ` Vincent Mailhol
2026-05-17 13:55 ` [PATCH 2/2] can: peak_usb: validate URB length in pcan_usb_pro_decode_buf() Berkant Koc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260517-can-usb-fix-cover@berkoc.com \
--to=me@berkoc.com \
--cc=kernel@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=stephane.grosjean@hms-networks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox