Re: [PATCH net v2 2/4] net: mvpp2: limit XDP frame size to the RX buffer

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Changing MTU to jumbo frames switches to shared buffers without detaching XDP, leading to NULL pointer dereference.
--

commit 6697a25a0b55fb9d610bfbe672d3935e951e1d53
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. This initializes the XDP buffer with
bm_pool->frag_size so XDP tailroom matches the actual buffer backing the
packet.

> 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 is a pre-existing issue, but is there a problem with XDP and jumbo
frames here?

If mvpp2_change_mtu() is called with an MTU that requires jumbo frames but is
smaller than MVPP2_MAX_RX_BUF_SIZE, it allows the MTU change and switches to
shared pools by calling mvpp2_bm_switch_buffers().

This destroys the page_pool structures and sets priv->percpu_pools to false,
but the XDP program remains attached.

Later, when packets arrive in 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;
	}

Because priv->percpu_pools is now false, pp remains NULL.

When mvpp2_run_xdp() is called with this NULL pp, and the XDP program returns
XDP_DROP, it unconditionally calls page_pool_put_page() with the NULL pp and
a non-page-pool page:

	case XDP_DROP:
		page = virt_to_head_page(xdp->data);
		page_pool_put_page(pp, page, sync, true);

Could this cause a kernel panic when XDP drops or redirects a packet after
an MTU change?

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