From: Maoyi Xie <maoyixie.tju@gmail.com>
To: Veerasenareddy Burru <vburru@marvell.com>,
Sathesh Edara <sedara@marvell.com>,
Satananda Burla <sburla@marvell.com>,
Shinas Rasheed <srasheed@marvell.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Guangshuo Li <lgs201920130244@gmail.com>,
David Carlier <devnexen@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net v4 3/3] octeon_ep_vf: fix skb frags overflow in the RX path
Date: Mon, 6 Jul 2026 23:02:08 +0800 [thread overview]
Message-ID: <20260706150208.2944898-4-maoyixie.tju@gmail.com> (raw)
In-Reply-To: <20260706150208.2944898-1-maoyixie.tju@gmail.com>
__octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
driver. buff_info->len comes from the device response header. The loop adds
one fragment per buffer_size chunk with no check against MAX_SKB_FRAGS. A
long packet yields about 18 fragments. That is one past the default
MAX_SKB_FRAGS of 17. skb_add_rx_frag() then 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 those descriptors. It also frees the head page
and every fragment page. The previous patch added those frees to the inline
drop path. 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 | 50 ++++++++++++-------
1 file changed, 32 insertions(+), 18 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 302559b16b..e7733b41a1 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,31 @@ 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,
+ void *resp_hw, u32 *read_idx, u32 *desc_used)
+{
+ u16 data_len = buff_info->len - oq->max_single_buffer_size;
+
+ put_page(virt_to_page(resp_hw));
+ (*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];
+ put_page(buff_info->page);
+ 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.
*
@@ -432,27 +457,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, resp_hw, &read_idx, &desc_used);
+ continue;
+ }
+
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
- put_page(virt_to_page(resp_hw));
- 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];
- put_page(buff_info->page);
- 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, resp_hw, &read_idx, &desc_used);
continue;
}
rx_bytes += buff_info->len;
--
2.34.1
prev parent reply other threads:[~2026-07-06 15:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 15:02 [PATCH net v4 0/3] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak Maoyi Xie
2026-07-06 15:02 ` [PATCH net v4 1/3] octeon_ep: fix skb frags overflow in the RX path Maoyi Xie
2026-07-06 15:02 ` [PATCH net v4 2/3] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure Maoyi Xie
2026-07-06 16:10 ` Maciej Fijalkowski
2026-07-06 15:02 ` Maoyi Xie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260706150208.2944898-4-maoyixie.tju@gmail.com \
--to=maoyixie.tju@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=devnexen@gmail.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=lgs201920130244@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sburla@marvell.com \
--cc=sedara@marvell.com \
--cc=srasheed@marvell.com \
--cc=vburru@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox