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

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.

Hi Jakub,

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

Thanks,
Maoyi

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