Re: [PATCH net] hinic3: bound the Rx fragment count to MAX_SKB_FRAGS

[Sebastian Andrzej Siewior]

On 2026-10-10 12:09:01 [+0900], Yehyeong Lee wrote:
> hinic3_rx_poll() takes the packet length from the Rx completion
> descriptor and turns it into a fragment count:
> 
>       pkt_len = RQ_CQE_SGE_GET(vlan_len, LEN);
>       sge_num = pkt_len >> rxq->buf_len_shift ...
> 
> RQ_CQE_SGE_LEN_MASK is a 16-bit field, so pkt_len is up to 65535 and
> sge_num up to 32 with the default 2048-byte buffers.  packaging_skb()
> then calls skb_add_rx_frag() sge_num times without checking the count
> against MAX_SKB_FRAGS, so a device reporting a length above
> MAX_SKB_FRAGS * buf_len writes fragment descriptors past the end of the
> skb's shared info array.
> 
> Driving the receive path with an out-of-range length reports under
> KASAN:
> 
>       BUG: KASAN: slab-out-of-bounds in hinic3_fetch_rx_buffer [hinic3]
>       Write of size 8 ...
>       The buggy address belongs to the object ...
>        which belongs to the cache skbuff_small_head of size 704
> 
> The length is chosen by the device and an skb cannot hold more than
> MAX_SKB_FRAGS fragments, so drop a frame that needs more instead of
> overrunning the array.  The buffers it claimed are already posted on the
> ring, so return them to the page pool and advance the consumer index
> over them to keep it in step with the device.
> 
> Fixes: 17fcb3dc12bb ("hinic3: module initialization and tx/rx logic")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Yehyeong Lee <yhlee@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>

How do you run into this? With the default 17 frags and 2048 buffers
your packet is larger than 17 * 2048 = 34KiB. Is this with a large MTU
or does the HW merge packets on its own? Ideally you would like to avoid
this from happening. The user gets just a dropped packet with no clue
what is wrong.

Sebastian