All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gunter Woytowitz" <gunter@vcinity.io>
Cc: bpf@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net] net: mana: never hand a non-page_pool buffer to XDP
Date: Fri, 11 Sep 2026 15:18:57 +0000	[thread overview]
Message-ID: <20260911151858.5835B1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910-mana-xdp-pagepool-v1-1-dab140d91fed@vcinity.io>

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

New issues:
- [High] Bypassing pre-allocated buffers when XDP is attached defeats anti-OOM protections, risking permanent interface disablement.

Pre-existing issues:
- [Critical] Dangling pointer in apc->bpf_prog leading to Use-After-Free and Double Free if mana_pre_alloc_rxbufs fails.
--

commit 47baeb3edbb2306dafb469762d4ed1350e2c78f3
Author: Gunter Woytowitz <gunter@vcinity.io>

net: mana: never hand a non-page_pool buffer to XDP

This commit ensures that all buffers handled by XDP are allocated from
the page_pool to prevent warnings when __xdp_return() frees them. It
bypasses the pre-allocated buffers when an XDP program is attached,
falling back to dynamic allocation. Unused pre-allocated buffers are
safely freed by existing cleanup paths.

> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index 7a1ac853e3abc..a2cb667530a06 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -2925,7 +2925,14 @@ static int mana_fill_rx_oob(struct mana_recv_buf_oob *rx_oob, u32 mem_key,
>  	dma_addr_t da;
>  	void *va;
>  
> -	if (mpc->rxbufs_pre)
> +	/* The pre-allocated buffers come from dev_alloc_pages(), not from the
> +	 * rxq's page_pool. With a program attached any buffer can reach
> +	 * __xdp_return(), which returns it to the pool the rxq registered, so
> +	 * fill from the pool instead. The unused pre-allocated buffers are
> +	 * released by the mana_pre_dealloc_rxbufs() every caller already runs
> +	 * after mana_attach().
> +	 */
> +	if (mpc->rxbufs_pre && !mana_xdp_get(mpc))
>  		va = mana_get_rxbuf_pre(rxq, &da);
>  	else
>  		va = mana_get_rxfrag(rxq, dev, &da, &from_pool, &pp_page,

[Severity: High]
Does bypassing the pre-allocated buffers when XDP is attached defeat the
anti-OOM protections?

When attaching an XDP program under memory pressure, mana_pre_alloc_rxbufs()
succeeds, but the dynamic page_pool allocations in mana_fill_rx_oob()
can now fail.

If mana_attach() fails halfway through due to these allocation failures:

drivers/net/ethernet/microsoft/mana/mana_bpf.c:mana_xdp_set() {
    ...
		err = mana_attach(ndev);
		if (err) {
			netdev_err(ndev,
				   "mana_attach failed at xdp set: %d\n", err);
			NL_SET_ERR_MSG_MOD(extack,
					   "XDP: Re-config failed at attach");
			goto err_dealloc_rxbuffs;
		}
    ...
}

Could this leave the network interface permanently detached until manually
reset, effectively doubling the peak memory requirement during the XDP attach
process?


[Severity: Critical]
This is a pre-existing issue, but I noticed a potential use-after-free
in mana_xdp_set() during error handling.

drivers/net/ethernet/microsoft/mana/mana_bpf.c:mana_xdp_set() {
    ...
	apc->bpf_prog = prog;

	if (apc->port_is_up) {
		/* Pre-allocate buffers to prevent failure in mana_attach */
		err = mana_pre_alloc_rxbufs(apc, ndev->mtu, apc->num_queues);
		if (err) {
			NL_SET_ERR_MSG_MOD(extack,
					   "XDP: Insufficient memory for tx/rx re-config");
			return err;
		}
    ...
}

If mana_pre_alloc_rxbufs() fails, we return early without restoring
apc->bpf_prog to old_prog.

Can this leave a dangling pointer in apc->bpf_prog?

The caller dev_xdp_attach() in net/core/dev.c drops the reference to the
program on error, freeing it. A subsequent call to mana_xdp_set() will read
this pointer as old_prog and call bpf_prog_put(old_prog).

Will this result in a double-free of the BPF program?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910-mana-xdp-pagepool-v1-1-dab140d91fed@vcinity.io?part=1

      parent reply	other threads:[~2026-09-11 15:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 15:17 [PATCH net] net: mana: never hand a non-page_pool buffer to XDP Gunter Woytowitz via B4 Relay
2026-09-10 15:17 ` Gunter Woytowitz
2026-09-11 11:12 ` Simon Horman
2026-09-11 14:31   ` Gunter Woytowitz
2026-09-11 15:18 ` sashiko-bot [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=20260911151858.5835B1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=gunter@vcinity.io \
    --cc=linux-hyperv@vger.kernel.org \
    --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.