Re: [PATCH net v2 1/2] net: usb: pegasus: do not advance rx_skb->data on dropped frames

[Simon Horman]

On Wed, Oct 21, 2026 at 10:03:09AM +0800, Wei Jie Law wrote:
> For the 0x8513 chip, read_bulk_callback() skips the 2-byte receive
> header by advancing pegasus->rx_skb->data in place. This is done before
> the pkt_len > PEGASUS_MTU check, and when that check drops the frame
> the goon path resubmits the same skb with the advanced rx_skb->data as
> the transfer buffer, still PEGASUS_MTU bytes long.
> 
> Every frame with an oversized length field therefore moves the receive
> buffer two more bytes towards the end of the skb data area. A device
> that keeps sending such frames makes the host controller write received
> data over skb_shared_info and past the end of the allocation, and the
> corrupted skb_shared_info is used when the skb is eventually freed.
> With an emulated device sending frames filled with 0x5a on a KASAN
> kernel:
> 
>   BUG: KASAN: slab-out-of-bounds in dummy_timer+0xade/0x3f00 [dummy_hcd]
>   Write of size 1536 at addr ffff888105821202 by task swapper/1/0
>   ...
>   Oops: general protection fault, probably for non-canonical address 0xeb4b474b4b4b4b4c: 0000 [#1] PREEMPT SMP KASAN NOPTI
>   KASAN: maybe wild-memory-access in range [0x5a5a5a5a5a5a5a60-0x5a5a5a5a5a5a5a67]
>   RIP: 0010:skb_release_data+0x36f/0x800
> 
> Only skip the header with skb_reserve() once the frame is going to be
> passed up, so the receive buffer always starts at the beginning of the
> skb data area. Unlike the old pointer adjustment, skb_reserve() also
> moves skb->tail, so the two header bytes now count against the buffer
> size: lower the length limit for the 0x8513 accordingly, otherwise a
> pkt_len of PEGASUS_MTU - 1 or PEGASUS_MTU would trip skb_over_panic().
> 
> Found by code review with LLM assistance and reproduced with an
> emulated USB device (raw-gadget + dummy_hcd).
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: LLM
> Signed-off-by: Wei Jie Law <law.wei.jie@xxxxxxxxxxxxxx>

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>