* [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path @ 2026-07-02 18:05 Maoyi Xie 2026-07-02 18:05 ` [PATCH net v2 1/2] octeon_ep: " Maoyi Xie 2026-07-02 18:05 ` [PATCH net v2 2/2] octeon_ep_vf: " Maoyi Xie 0 siblings, 2 replies; 5+ messages in thread From: Maoyi Xie @ 2026-07-02 18:05 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. v2: - move the check before (napi_)build_skb() so the driver does not build an skb only to free it, per Maciej Fijalkowski. - the frag count check uses the same u16 length the fragment loop uses. The repeated linear/non-linear code in octeon_ep_vf that Maciej noted is a separate cleanup, left for net-next to keep this fix minimal. v1: https://lore.kernel.org/r/20260701112825.1653044-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 | 20 +++++++++++++++++++ 2 files changed, 29 insertions(+) -- 2.34.1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path 2026-07-02 18:05 [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie @ 2026-07-02 18:05 ` Maoyi Xie 2026-07-03 12:01 ` Maciej Fijalkowski 2026-07-02 18:05 ` [PATCH net v2 2/2] octeon_ep_vf: " Maoyi Xie 1 sibling, 1 reply; 5+ messages in thread From: Maoyi Xie @ 2026-07-02 18:05 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> --- 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] 5+ messages in thread
* Re: [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path 2026-07-02 18:05 ` [PATCH net v2 1/2] octeon_ep: " Maoyi Xie @ 2026-07-03 12:01 ` Maciej Fijalkowski 0 siblings, 0 replies; 5+ messages in thread From: Maciej Fijalkowski @ 2026-07-03 12:01 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 Fri, Jul 03, 2026 at 02:05:17AM +0800, Maoyi Xie wrote: > __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 [flat|nested] 5+ messages in thread
* [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path 2026-07-02 18:05 [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie 2026-07-02 18:05 ` [PATCH net v2 1/2] octeon_ep: " Maoyi Xie @ 2026-07-02 18:05 ` Maoyi Xie 2026-07-03 12:11 ` Maciej Fijalkowski 1 sibling, 1 reply; 5+ messages in thread From: Maoyi Xie @ 2026-07-02 18:05 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. Its descriptors are drained 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 <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 | 20 +++++++++++++++++++ 1 file changed, 20 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 d982474082..7af6a80671 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 @@ -431,6 +431,26 @@ 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) { + 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); + } + continue; + } + skb = napi_build_skb((void *)resp_hw, PAGE_SIZE); if (!skb) { oq->stats->alloc_failures++; -- 2.34.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path 2026-07-02 18:05 ` [PATCH net v2 2/2] octeon_ep_vf: " Maoyi Xie @ 2026-07-03 12:11 ` Maciej Fijalkowski 0 siblings, 0 replies; 5+ messages in thread From: Maciej Fijalkowski @ 2026-07-03 12:11 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 Fri, Jul 03, 2026 at 02:05:18AM +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. Its descriptors are > drained 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 <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 | 20 +++++++++++++++++++ > 1 file changed, 20 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 d982474082..7af6a80671 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 > @@ -431,6 +431,26 @@ 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) { > + 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); > + } > + continue; > + } This is exactly repeated code for !skb case below, right? Please pull it out to helper function then. > + > skb = napi_build_skb((void *)resp_hw, PAGE_SIZE); > if (!skb) { > oq->stats->alloc_failures++; > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-07-03 12:12 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-07-02 18:05 [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie 2026-07-02 18:05 ` [PATCH net v2 1/2] octeon_ep: " Maoyi Xie 2026-07-03 12:01 ` Maciej Fijalkowski 2026-07-02 18:05 ` [PATCH net v2 2/2] octeon_ep_vf: " Maoyi Xie 2026-07-03 12:11 ` Maciej Fijalkowski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox