From: sashiko-bot@kernel.org
To: "Muhammad Falak R Wani" <falakreyaz@gmail.com>
Cc: bpf@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net-next v2] net: mana: remove unreachable dead code in mana_bpf()
Date: Thu, 03 Sep 2026 09:10:50 +0000 [thread overview]
Message-ID: <20260903091050.84B731F000E9@smtp.kernel.org> (raw)
In-Reply-To: <3d8b67307df6fefdc18743274cef3de4fca0e7de.1788339612.git.falakreyaz@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Failure to restore `apc->bpf_prog` on error path causes Use-After-Free.
--
commit 26086af444af1d715f516a007146a7dd00ce97c6
Author: Muhammad Falak R Wani <falakreyaz@gmail.com>
net: mana: remove unreachable dead code in mana_bpf()
This commit cleans up mana_bpf() by removing an unreachable return statement
after a switch statement that already unconditionally returns.
Link: https://lore.kernel.org/netdev/DKWZHHOFA1F3.1EL2DMFNGMP0Y@gmail.com/
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_bpf.c b/drivers/net/ethernet/microsoft/mana/mana_bpf.c
> index 53308e139cbe9..70bb8c9dc3413 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_bpf.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_bpf.c
[ ... ]
This is a pre-existing issue, but while reviewing this patch I noticed a
potential problem in the adjacent mana_xdp_set() function when it handles
allocation failures:
drivers/net/ethernet/microsoft/mana/mana_bpf.c:mana_xdp_set() {
...
apc->bpf_prog = prog;
if (apc->port_is_up) {
...
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;
}
...
}
[Severity: High]
Does this error path leave a dangling pointer in apc->bpf_prog?
It appears that if mana_pre_alloc_rxbufs() fails, the function returns
immediately without restoring apc->bpf_prog = old_prog. The generic XDP caller
will see the failure, assume the driver rejected the program, and drop its BPF
program reference.
Could this leave a freed pointer in apc->bpf_prog that might be dereferenced
when the interface is later restarted or accessed?
> @@ -253,7 +253,6 @@ static int mana_xdp_set(struct net_device *ndev, struct bpf_prog *prog,
> int mana_bpf(struct net_device *ndev, struct netdev_bpf *bpf)
> {
> struct netlink_ext_ack *extack = bpf->extack;
> - int ret;
>
> switch (bpf->command) {
> case XDP_SETUP_PROG:
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/3d8b67307df6fefdc18743274cef3de4fca0e7de.1788339612.git.falakreyaz@gmail.com?part=1
next prev parent reply other threads:[~2026-09-03 9:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 9:10 [PATCH net-next v2] net: mana: remove unreachable dead code in mana_bpf() Muhammad Falak R Wani
2026-09-03 9:10 ` sashiko-bot [this message]
2026-09-04 23:10 ` patchwork-bot+netdevbpf
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=20260903091050.84B731F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=falakreyaz@gmail.com \
--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.