* [PATCH net v3 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path @ 2026-07-04 6:15 Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 1/2] octeon_ep: " Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 2/2] octeon_ep_vf: " Maoyi Xie 0 siblings, 2 replies; 4+ messages in thread From: Maoyi Xie @ 2026-07-04 6:15 UTC (permalink / raw) To: Veerasenareddy Burru, Sathesh Edara Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel Both octeon_ep and octeon_ep_vf build an skb for a multi-buffer RX packet by adding one fragment per buffer_size chunk of a device-reported length. Neither bounds the count 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[]. Each driver now checks the fragment count before it builds the skb and drops a packet that would not fit. v3: - octeon_ep_vf: pull the drop drain into octep_vf_oq_drop_rx(). The overflow drop and the napi_build_skb failure path both use it. Suggested by Maciej Fijalkowski. - octeon_ep: add Maciej's Reviewed-by. v1: https://lore.kernel.org/r/20260701112825.1653044-1-maoyixie.tju@gmail.com v2: https://lore.kernel.org/r/20260702180518.2013324-1-maoyixie.tju@gmail.com Maoyi Xie (2): octeon_ep: fix skb frags overflow in the RX path octeon_ep_vf: fix skb frags overflow in the RX path .../net/ethernet/marvell/octeon_ep/octep_rx.c | 9 ++++ .../marvell/octeon_ep_vf/octep_vf_rx.c | 46 ++++++++++++------- 2 files changed, 39 insertions(+), 16 deletions(-) -- 2.34.1 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH net v3 1/2] octeon_ep: fix skb frags overflow in the RX path 2026-07-04 6:15 [PATCH net v3 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie @ 2026-07-04 6:15 ` Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 2/2] octeon_ep_vf: " Maoyi Xie 1 sibling, 0 replies; 4+ messages in thread From: Maoyi Xie @ 2026-07-04 6:15 UTC (permalink / raw) To: Veerasenareddy Burru, Sathesh Edara Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel __octep_oq_process_rx() builds an skb for a multi-buffer packet by adding one fragment per buffer_size chunk: data_len = buff_info->len - oq->max_single_buffer_size; while (data_len) { ... skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0, buff_info->len, buff_info->len); ... } buff_info->len comes from the device response header (be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to about 3776 on 4K pages, so a full packet yields about 18 fragments. That is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past shinfo->frags[]. The fragment count is now checked before build_skb(). A packet that needs more fragments than the skb can hold is dropped. octep_oq_drop_rx() consumes its descriptors like the build_skb failure path. The same class was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic: fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path"). Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support") Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> --- drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c index e6ebc7e44a..bdbed58c7b 100644 --- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c @@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct, octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used); + if (buff_info->len > oq->max_single_buffer_size) { + u16 data_len = buff_info->len - oq->max_single_buffer_size; + + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) { + octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used); + continue; + } + } + skb = build_skb((void *)resp_hw, PAGE_SIZE); if (!skb) { octep_oq_drop_rx(oq, buff_info, -- 2.34.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH net v3 2/2] octeon_ep_vf: fix skb frags overflow in the RX path 2026-07-04 6:15 [PATCH net v3 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 1/2] octeon_ep: " Maoyi Xie @ 2026-07-04 6:15 ` Maoyi Xie 2026-07-06 9:40 ` Maciej Fijalkowski 1 sibling, 1 reply; 4+ messages in thread From: Maoyi Xie @ 2026-07-04 6:15 UTC (permalink / raw) To: Veerasenareddy Burru, Sathesh Edara Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel __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 fragment count is now checked before napi_build_skb(). A packet that needs more fragments than the skb can hold is dropped. octep_vf_oq_drop_rx() drains its descriptors. The napi_build_skb() failure path now uses the same helper. Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> --- .../marvell/octeon_ep_vf/octep_vf_rx.c | 46 ++++++++++++------- 1 file changed, 30 insertions(+), 16 deletions(-) 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 d982474082..aa77b673ae 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 @@ -357,6 +357,29 @@ static inline u32 octep_vf_oq_next_idx(struct octep_vf_oq *oq, u32 idx) return (idx + 1 == oq->max_count) ? 0 : idx + 1; } +static void octep_vf_oq_drop_rx(struct octep_vf_oq *oq, + struct octep_vf_rx_buffer *buff_info, + u32 *read_idx, u32 *desc_used) +{ + u16 data_len = buff_info->len - oq->max_single_buffer_size; + + (*desc_used)++; + *read_idx = octep_vf_oq_next_idx(oq, *read_idx); + 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); + } +} + /** * __octep_vf_oq_process_rx() - Process hardware Rx queue and push to stack. * @@ -431,25 +454,16 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct, struct skb_shared_info *shinfo; u16 data_len; + data_len = buff_info->len - oq->max_single_buffer_size; + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) { + octep_vf_oq_drop_rx(oq, buff_info, &read_idx, &desc_used); + continue; + } + skb = napi_build_skb((void *)resp_hw, PAGE_SIZE); if (!skb) { oq->stats->alloc_failures++; - desc_used++; - read_idx = octep_vf_oq_next_idx(oq, read_idx); - data_len = buff_info->len - oq->max_single_buffer_size; - 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); - } + octep_vf_oq_drop_rx(oq, buff_info, &read_idx, &desc_used); continue; } rx_bytes += buff_info->len; -- 2.34.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH net v3 2/2] octeon_ep_vf: fix skb frags overflow in the RX path 2026-07-04 6:15 ` [PATCH net v3 2/2] octeon_ep_vf: " Maoyi Xie @ 2026-07-06 9:40 ` Maciej Fijalkowski 0 siblings, 0 replies; 4+ messages in thread From: Maciej Fijalkowski @ 2026-07-06 9:40 UTC (permalink / raw) To: Maoyi Xie Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel On Sat, Jul 04, 2026 at 02:15:11PM +0800, Maoyi Xie wrote: > __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 fragment count is now checked before napi_build_skb(). A packet that > needs more fragments than the skb can hold is dropped. > octep_vf_oq_drop_rx() drains its descriptors. The napi_build_skb() > failure path now uses the same helper. > > Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support") > Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> > Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> > Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> > --- > .../marvell/octeon_ep_vf/octep_vf_rx.c | 46 ++++++++++++------- > 1 file changed, 30 insertions(+), 16 deletions(-) > > 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 d982474082..aa77b673ae 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 > @@ -357,6 +357,29 @@ static inline u32 octep_vf_oq_next_idx(struct octep_vf_oq *oq, u32 idx) > return (idx + 1 == oq->max_count) ? 0 : idx + 1; > } > > +static void octep_vf_oq_drop_rx(struct octep_vf_oq *oq, > + struct octep_vf_rx_buffer *buff_info, > + u32 *read_idx, u32 *desc_used) > +{ > + u16 data_len = buff_info->len - oq->max_single_buffer_size; > + > + (*desc_used)++; > + *read_idx = octep_vf_oq_next_idx(oq, *read_idx); > + 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); > + } > +} > + > /** > * __octep_vf_oq_process_rx() - Process hardware Rx queue and push to stack. > * > @@ -431,25 +454,16 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct, > struct skb_shared_info *shinfo; > u16 data_len; > > + data_len = buff_info->len - oq->max_single_buffer_size; > + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) { > + octep_vf_oq_drop_rx(oq, buff_info, &read_idx, &desc_used); > + continue; > + } > + > skb = napi_build_skb((void *)resp_hw, PAGE_SIZE); > if (!skb) { > oq->stats->alloc_failures++; > - desc_used++; > - read_idx = octep_vf_oq_next_idx(oq, read_idx); > - data_len = buff_info->len - oq->max_single_buffer_size; > - 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); > - } > + octep_vf_oq_drop_rx(oq, buff_info, &read_idx, &desc_used); > continue; > } > rx_bytes += buff_info->len; > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-07-06 9:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-07-04 6:15 [PATCH net v3 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 1/2] octeon_ep: " Maoyi Xie 2026-07-04 6:15 ` [PATCH net v3 2/2] octeon_ep_vf: " Maoyi Xie 2026-07-06 9:40 ` Maciej Fijalkowski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox