From: sashiko-bot@kernel.org
To: "Sun Jian" <sun.jian.kdev@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v3 2/2] selftests/bpf: Cover generic devmap egress last-dst rewrite
Date: Thu, 11 Jun 2026 04:47:21 +0000 [thread overview]
Message-ID: <20260611044722.174351F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260611043317.512843-3-sun.jian.kdev@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Uninitialized `net_config` is passed to `cleanup_network()` on early error paths, causing arbitrary shell commands to be executed via `system()`.
--
commit 60bbc3bd1e74368d2d682d8956f86b733750dfd9
Author: Sun Jian <sun.jian.kdev@gmail.com>
selftests/bpf: Cover generic devmap egress last-dst rewrite
This patch strengthens xdp_veth_egress to check that destinations observe
the correct MAC address for their own egress ifindex. It also adds a new
generic XDP last-destination test to cover cases where earlier destinations
do not have a devmap egress program.
> diff --git a/tools/testing/selftests/bpf/prog_tests/test_xdp_veth.c b/tools/testing/selftests/bpf/prog_tests/test_xdp_veth.c
> index 3e98a16659362..681415cacb75c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/test_xdp_veth.c
> +++ b/tools/testing/selftests/bpf/prog_tests/test_xdp_veth.c
[ ... ]
> +static void xdp_veth_egress_last_dst(u32 flags)
> +{
[ ... ]
> + struct net_configuration net_config;
> + int mac_map, egress_map, res_map;
> + struct nstoken *nstoken = NULL;
> + struct xdp_dummy *xdp_dummy;
> + __be64 last_mac = 0;
> + bool found = false;
> + int err;
> + int i;
> +
> + xdp_dummy = xdp_dummy__open_and_load();
> + if (!ASSERT_OK_PTR(xdp_dummy, "xdp_dummy__open_and_load"))
> + return;
> +
> + xdp_redirect_multi_kern = xdp_redirect_multi_kern__open_and_load();
> + if (!ASSERT_OK_PTR(xdp_redirect_multi_kern, "xdp_redirect_multi_kern__open_and_load"))
> + goto destroy_xdp_dummy;
> +
> + xdp_redirect_map = xdp_redirect_map__open_and_load();
> + if (!ASSERT_OK_PTR(xdp_redirect_map, "xdp_redirect_map__open_and_load"))
> + goto destroy_xdp_redirect_multi_kern;
> +
> + if (!ASSERT_OK(create_network(&net_config), "create network"))
> + goto destroy_xdp_redirect_map;
[ ... ]
> +destroy_xdp_redirect_map:
> + close_netns(nstoken);
> + xdp_redirect_map__destroy(xdp_redirect_map);
> +destroy_xdp_redirect_multi_kern:
> + xdp_redirect_multi_kern__destroy(xdp_redirect_multi_kern);
> +destroy_xdp_dummy:
> + xdp_dummy__destroy(xdp_dummy);
> +
> + cleanup_network(&net_config);
[Severity: High]
This isn't a bug introduced by this patch, but does this early error
handling path pass uninitialized stack memory to cleanup_network()?
If xdp_redirect_multi_kern__open_and_load() or
xdp_redirect_map__open_and_load() fail before create_network() is called,
the goto labels eventually reach cleanup_network(&net_config).
Since cleanup_network() passes net_config fields like ns0_name to SYS_NOFAIL
which executes system commands, could passing uninitialized stack garbage
here lead to unpredictable shell command execution as root?
Would it be safer to zero-initialize net_config with `= {}` when declaring it?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611043317.512843-1-sun.jian.kdev@gmail.com?part=2
next prev parent reply other threads:[~2026-06-11 4:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 4:33 [PATCH bpf v3 0/2] bpf: Fix generic devmap egress skb sharing Sun Jian
2026-06-11 4:33 ` [PATCH bpf v3 1/2] bpf: Run generic devmap egress prog on private skb Sun Jian
2026-06-11 4:58 ` sashiko-bot
2026-06-11 7:10 ` sun jian
2026-06-11 4:33 ` [PATCH bpf v3 2/2] selftests/bpf: Cover generic devmap egress last-dst rewrite Sun Jian
2026-06-11 4:47 ` sashiko-bot [this message]
2026-06-11 7:14 ` sun jian
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=20260611044722.174351F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sun.jian.kdev@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox