All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Til Kaiser" <mail@tk154.de>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net v5 2/4] net: mvpp2: limit XDP frame size to the RX buffer
Date: Mon, 08 Jun 2026 13:51:11 +0000	[thread overview]
Message-ID: <20260608135112.1AF451F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260607134943.21996-3-mail@tk154.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Changing MTU to a value > 1664 silently disables per-CPU pools while leaving XDP programs attached, leading to a NULL pointer dereference when XDP drops or redirects packets.
--

commit de2e76bdbee6c2ad0c3dc5a24f4854767f944f85
Author: Til Kaiser <mail@tk154.de>

net: mvpp2: limit XDP frame size to the RX buffer

mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size.

> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 92a701f4fe3f5..3372ed27cc8d6 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3979,7 +3979,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  			else
>  				xdp_rxq = &rxq->xdp_rxq_long;
>  
> -			xdp_init_buff(&xdp, PAGE_SIZE, xdp_rxq);
> +			xdp_init_buff(&xdp, bm_pool->frag_size, xdp_rxq);
>  			xdp_prepare_buff(&xdp, data,
>  					 MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM,
>  					 rx_bytes, true);

[Severity: High]
This isn't a bug introduced by this patch, but could this lead to a NULL
pointer dereference in the XDP path?

If the MTU is changed to a value > 1664 on another port, mvpp2_change_mtu()
globally disables per-CPU pools:

drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:mvpp2_change_mtu() {
    ...
	if (priv->percpu_pools) {
		netdev_warn(dev, "mtu %d too high, switching to shared buffers", mtu);
		mvpp2_bm_switch_buffers(priv, false);
	}
    ...
}

This leaves other ports with their XDP programs still attached but without
per-CPU pools. When a packet arrives, mvpp2_rx() leaves pp as NULL:

drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:mvpp2_rx() {
    ...
		if (port->priv->percpu_pools) {
			pp = port->priv->page_pool[pool];
			dma_dir = page_pool_get_dma_dir(pp);
		} else {
			dma_dir = DMA_FROM_DEVICE;
		}
    ...
}

Shortly after xdp_prepare_buff() in mvpp2_rx(), mvpp2_run_xdp() is called
with the NULL pp. If the XDP program drops or redirects the packet, does
mvpp2_run_xdp() pass the NULL pp to page_pool_put_page(), causing a panic?

drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:mvpp2_run_xdp() {
    ...
	case XDP_DROP:
		ret = MVPP2_XDP_DROPPED;
		page = virt_to_head_page(xdp->data);
		page_pool_put_page(pp, page, sync, true);
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260607134943.21996-1-mail@tk154.de?part=2

  reply	other threads:[~2026-06-08 13:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-07 13:49 [PATCH net v5 0/4] net: mvpp2: fix XDP RX buffer handling Til Kaiser
2026-06-07 13:49 ` [PATCH net v5 1/4] net: mvpp2: sync RX data at the hardware packet offset Til Kaiser
2026-06-07 13:49 ` [PATCH net v5 2/4] net: mvpp2: limit XDP frame size to the RX buffer Til Kaiser
2026-06-08 13:51   ` sashiko-bot [this message]
2026-06-07 13:49 ` [PATCH net v5 3/4] net: mvpp2: refill RX buffers before XDP or skb use Til Kaiser
2026-06-07 13:49 ` [PATCH net v5 4/4] net: mvpp2: build skb from XDP-adjusted data on XDP_PASS Til Kaiser

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=20260608135112.1AF451F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=mail@tk154.de \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.