Re: [PATCH net 2/2] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date: 2026-07-01 14:18:18
Also in:
lkml
On Wed, Jul 01, 2026 at 07:28:25PM +0800, Maoyi Xie wrote:
quoted hunk ↗ jump to hunk
__octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF driver. buff_info->len comes from the device response header, and one fragment is added per buffer_size chunk with no check against MAX_SKB_FRAGS. A long packet yields about 18 fragments, one past the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past shinfo->frags[]. The driver now drops a packet that would need more fragments than the skb can hold. It drains the descriptors the same way the build_skb failure path does. Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Co-developed-by: Kaixuan Li <redacted> Signed-off-by: Kaixuan Li <redacted> Signed-off-by: Maoyi Xie <redacted> --- .../ethernet/marvell/octeon_ep_vf/octep_vf_rx.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c index d982474082423..2e666df26b4c3 100644 --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c@@ -463,6 +463,23 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct, shinfo = skb_shinfo(skb); data_len = buff_info->len - oq->max_single_buffer_size; + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) { + dev_kfree_skb_any(skb); + while (data_len) { + dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr, + PAGE_SIZE, DMA_FROM_DEVICE); + buff_info = (struct octep_vf_rx_buffer *) + &oq->buff_info[read_idx]; + buff_info->page = NULL; + if (data_len < oq->buffer_size) + data_len = 0; + else + data_len -= oq->buffer_size; + desc_used++; + read_idx = octep_vf_oq_next_idx(oq, read_idx); + } + continue; + }
same suggestion/question here pluse there seems to be a bunch of repeated code between linear and non-linear skb processing paths...
while (data_len) {
dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
PAGE_SIZE, DMA_FROM_DEVICE);
--
2.34.1