[PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak

[PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak

[Maoyi Xie]

The octeon_ep and octeon_ep_vf RX paths add one skb fragment per buffer
with no bound against MAX_SKB_FRAGS. buff_info->len comes from the device
response header. A long packet needs about 18 fragments. That is one past
the default MAX_SKB_FRAGS of 17. skb_add_rx_frag() then writes past
shinfo->frags[]. Patch 2 bounds octeon_ep. Patch 4 bounds octeon_ep_vf.

Both drivers also leak the pages of a dropped multi-buffer packet. The
drop path unmaps each buffer but never frees its page. Patch 1 fixes
octeon_ep. Patch 3 is Guangshuo Li's fix for octeon_ep_vf. The overflow
drops in patch 2 and patch 4 reuse those helpers. They free their pages
too.

The drop drain length derives from the device length. It had no bound
against the ring. Patch 1 and patch 4 stop the drain after MAX_SKB_FRAGS
fragments. A valid packet never holds more. This keeps a bad device length
from running the drain past the ring.

v6:
 - octeon_ep: add patch 1 to free the dropped RX buffer pages, per Jakub
   Kicinski. The drop path leaked the head page and every fragment page.
   The overflow drop in patch 2 reuses that helper. The v5 cover deferred
   this fix to a follow-up.
 - octeon_ep, octeon_ep_vf: bound the drop drain to MAX_SKB_FRAGS. The drain
   length derives from the device length. A bad length could run it past
   the ring. This is defense in depth against a misbehaving device.

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
v3: https://lore.kernel.org/r/20260704061511.2350737-1-maoyixie.tju@gmail.com
v4: https://lore.kernel.org/r/20260706150208.2944898-1-maoyixie.tju@gmail.com
v5: https://lore.kernel.org/r/20260716063432.2908100-1-maoyixie.tju@gmail.com

Guangshuo Li (1):
  octeon_ep_vf: Fix RX page leak on napi_build_skb() failure

Maoyi Xie (3):
  octeon_ep: free the dropped RX buffer pages
  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 | 19 ++++++-
 .../marvell/octeon_ep_vf/octep_vf_rx.c        | 52 +++++++++++++------
 2 files changed, 53 insertions(+), 18 deletions(-)

--
2.34.1

[PATCH net v6 1/4] octeon_ep: free the dropped RX buffer pages

[Maoyi Xie]

octep_oq_drop_rx() drains a dropped multi-buffer RX packet but never
frees its pages. It unmaps each fragment descriptor and leaves the page
behind. It also reuses the head buff_info for every fragment.
octep_oq_next_pkt() then clears the head slot again instead of the
fragment slot. The fragment slots keep their page pointers. A later ring
teardown unmaps those descriptors a second time. The build_skb() failure
path frees no page either. The head page leaks too.

octep_oq_drop_rx() now indexes each fragment slot. It unmaps the slot and
frees its page. The unmap stays before the free to keep the DMA API
contract. The build_skb() failure path frees the head page.

buff_info->len comes from the device and is not bounded. The drain length
derives from it. A bad length could run the loop past the ring. It would
then free live pages of other packets. The loop now stops after
MAX_SKB_FRAGS fragments. A valid packet never holds more.

Fixes: eb592008f79b ("octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()")
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, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
index e6ebc7e44a..b0162fb9d9 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
@@ -388,9 +388,15 @@ static void octep_oq_drop_rx(struct octep_oq *oq,
 			     u32 *read_idx, u32 *desc_used)
 {
 	int data_len = buff_info->len - oq->max_single_buffer_size;
+	int i;
+
+	for (i = 0; i < MAX_SKB_FRAGS && data_len > 0; i++) {
+		struct page *page;
 
-	while (data_len > 0) {
+		buff_info = (struct octep_rx_buffer *)&oq->buff_info[*read_idx];
+		page = buff_info->page;
 		octep_oq_next_pkt(oq, buff_info, read_idx, desc_used);
+		put_page(page);
 		data_len -= oq->buffer_size;
 	}
 }
@@ -457,6 +463,7 @@ static int __octep_oq_process_rx(struct octep_device *oct,
 		if (!skb) {
 			octep_oq_drop_rx(oq, buff_info,
 					 &read_idx, &desc_used);
+			put_page(virt_to_page(resp_hw));
 			oq->stats->alloc_failures++;
 			continue;
 		}
-- 
2.34.1

[PATCH net v6 2/4] octeon_ep: fix skb frags overflow in the RX path

[Maoyi Xie]

__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. A full packet then yields about 18 fragments.
That is one more than the default MAX_SKB_FRAGS of 17. 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() frees
the fragment pages. This path frees the head page too. 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 | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
index b0162fb9d9..20c7b9f53e 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
@@ -459,6 +459,16 @@ 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) {
+			u32 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);
+				put_page(virt_to_page(resp_hw));
+				continue;
+			}
+		}
+
 		skb = build_skb((void *)resp_hw, PAGE_SIZE);
 		if (!skb) {
 			octep_oq_drop_rx(oq, buff_info,
-- 
2.34.1

[PATCH net v6 3/4] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure

[Maoyi Xie]

From: Guangshuo Li <lgs201920130244@gmail.com>

__octep_vf_oq_process_rx() clears buff_info->page before building an skb
from the RX page. On the success path the page is consumed by the skb,
either as the skb head or as an RX fragment.

If napi_build_skb() fails, however, the page is not consumed by an skb.
The error path advances the descriptor and leaves the ring slot cleared,
so the page is no longer tracked and is leaked. In the multi-fragment
case, the remaining fragment pages are also unmapped and removed from
their ring slots without being released.

Release the head page when napi_build_skb() fails, and release each
remaining fragment page before clearing its ring slot.

Fixes: dd66b4285470 ("octeon_ep_vf: add NULL check for napi_build_skb()")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c | 3 +++
 1 file changed, 3 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..302559b16b 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
@@ -418,6 +418,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
 			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);
 				continue;
@@ -434,6 +435,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
 			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;
@@ -442,6 +444,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
 						       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;
-- 
2.34.1

[PATCH net v6 4/4] octeon_ep_vf: fix skb frags overflow in the RX path

[Maoyi Xie]

__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 drain stops after MAX_SKB_FRAGS fragments. A
bad device length cannot run it past the ring. 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        | 53 ++++++++++++-------
 1 file changed, 34 insertions(+), 19 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..9d71937074 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,32 @@ 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)
+{
+	u32 data_len = buff_info->len - oq->max_single_buffer_size;
+	int i;
+
+	put_page(virt_to_page(resp_hw));
+	(*desc_used)++;
+	*read_idx = octep_vf_oq_next_idx(oq, *read_idx);
+	for (i = 0; i < MAX_SKB_FRAGS && data_len; i++) {
+		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.
  *
@@ -430,29 +456,18 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
 			read_idx = octep_vf_oq_next_idx(oq, read_idx);
 		} else {
 			struct skb_shared_info *shinfo;
-			u16 data_len;
+			u32 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

Re: [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak

[Jakub Kicinski]

On Wed, 22 Jul 2026 23:51:27 +0800 Maoyi Xie wrote:
> The octeon_ep and octeon_ep_vf RX paths add one skb fragment per buffer
> with no bound against MAX_SKB_FRAGS. buff_info->len comes from the device
> response header. A long packet needs about 18 fragments. That is one past
> the default MAX_SKB_FRAGS of 17. skb_add_rx_frag() then writes past
> shinfo->frags[]. Patch 2 bounds octeon_ep. Patch 4 bounds octeon_ep_vf.
> 
> Both drivers also leak the pages of a dropped multi-buffer packet. The
> drop path unmaps each buffer but never frees its page. Patch 1 fixes
> octeon_ep. Patch 3 is Guangshuo Li's fix for octeon_ep_vf. The overflow
> drops in patch 2 and patch 4 reuse those helpers. They free their pages
> too.
> 
> The drop drain length derives from the device length. It had no bound
> against the ring. Patch 1 and patch 4 stop the drain after MAX_SKB_FRAGS
> fragments. A valid packet never holds more. This keeps a bad device length
> from running the drain past the ring.

I'm asking you for the second time - why are you working on this driver?
Do you have HW to test this?
This driver is orphaned, it's been nothing but bugs for years, if nobody
has this HW we should just delete this crap.

Re: [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak

[Maoyi Xie]

Hi Jakub,

Sorry, I should have answered the first time. No, I do not have the hardware.

Thanks,
Maoyi

Re: [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak

[Jakub Kicinski]

On Thu, 23 Jul 2026 00:47:55 +0800 Maoyi Xie wrote:
> Hi Jakub,
> 
> Sorry, I should have answered the first time. No, I do not have the hardware.

Let's hold off on these fixes and please instead send a patch for
net-next to delete the driver. Try to CC folks from git history
who seem to have used it / had access to it in the past.
-- 
pw-bot: defer