Re: [PATCH 1/2] can: peak_usb: validate URB length in pcan_usb_fd_decode_buf()

[Vincent Mailhol]

On 17/05/2026 at 15:55, Berkant Koc wrote:
> pcan_usb_fd_decode_buf() walks records inside the bulk-in URB by reading
> the 12-byte struct pucan_msg header from the front of each record. The
> existing loop only verifies that msg_ptr is below msg_end before
> dereferencing rx_msg->size and rx_msg->type, which means a short URB
> that contains between 1 and 11 bytes of payload causes a two-byte
> out-of-bounds read of the rx_msg->size and rx_msg->type fields. The
> fragment check that follows compares the announced size against msg_end
> but lands after the header has already been read.
> 
> A malicious USB device that pretends to be a PEAK-System PCAN-USB-FD
> adapter (USB IDs 0c72:0012, 0c72:0014, 0c72:0016) can keep returning
> short bulk-in URBs and trigger this read on every poll cycle, leaking
> adjacent slab content via the dispatched decode paths or simply
> producing a KASAN slab-out-of-bounds report.
> 
> Apply the pattern from commit 6fe9f3279f7d ("can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header"):
> require that at least sizeof(struct pucan_msg) bytes remain before each
> iteration, and reject records whose announced size is smaller than the
> header itself.
> 
> Identified by static analysis.

Could you name which tool you used? Otherwise, this sentence adds little
value to the report.

> No KASAN trip available without specific PEAK CAN-FD hardware.
> 
> Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters")
> Cc: stable@xxxxxxxxxxxxxxx # 4.0+
> Signed-off-by: Berkant Koc <me@xxxxxxxxxx>

The code itself is OK. Not withstanding of above comment:

Reviewed-by: Vincent Mailhol <mailhol@xxxxxxxxxx>


Yours sincerely,
Vincent Mailhol