From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 19/21] selftests/bpf: Add __set_global() and __ret_global() test tags
Date: Sat, 26 Sep 2026 05:18:39 +0000 [thread overview]
Message-ID: <20260926051839.F28911F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926050143.2222664-1-yonghong.song@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] bpf: selftests: out-of-bounds heap access in access_global_var
- [Medium] bpf: selftests: multiple __set_global or __ret_global tags are silently overwritten
--
commit 81344b890bb87ceeed0ef105e0aab6e9d6797e2d
Author: Yonghong Song <yonghong.song@linux.dev>
selftests/bpf: Add __set_global() and __ret_global() test tags
This commit adds __set_global() and __ret_global() tags to the BPF
test loader. These tags allow setting a program's global variable before
execution and verifying its value afterwards.
> diff --git a/tools/testing/selftests/bpf/test_loader.c b/tools/testing/selftests/bpf/test_loader.c
> --- a/tools/testing/selftests/bpf/test_loader.c
> +++ b/tools/testing/selftests/bpf/test_loader.c
[ ... ]
> @@ -311,6 +326,142 @@ static int parse_caps(const char *str, __u64 *val, const char *name)
> +static int parse_global_var(const char *str, char **var, __u64 *val, const char *name)
> +{
> + const char *colon = strrchr(str, ':');
> + char *end;
[ ... ]
> + term = end + 1;
> + }
> +
> + free(*var);
> + *var = strndup(str, colon - str);
[Severity: Medium]
If a test author uses multiple __set_global() or __ret_global() tags in a
single test, does this silently overwrite the previous allocations? Only the
last tag seems to take effect, making it impossible to configure multiple
global variables in one test.
> + if (!*var) {
> + PRINT_FAIL("failed to allocate %s variable name\n", name);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static int access_global_var(struct bpf_object *obj, const char *name,
> + __u64 *val, bool set)
> +{
> + __u32 off, sz, zero = 0;
> + struct bpf_map *map;
> + size_t vsz;
> + void *buf;
> + int err;
> +
> + err = find_global_var(obj, name, &map, &off, &sz);
> + if (err)
> + return err;
> +
> + vsz = bpf_map__value_size(map);
> + buf = calloc(1, vsz);
> + if (!buf)
> + return -ENOMEM;
> +
> + err = bpf_map__lookup_elem(map, &zero, sizeof(zero), buf, vsz, 0);
> + if (err) {
> + PRINT_FAIL("failed to read '%s': %d\n", name, err);
> + goto out;
> + }
> + if (!set) {
> + *val = sz == 4 ? *(__u32 *)(buf + off) : *(__u64 *)(buf + off);
[Severity: Medium]
Is it possible to have an out-of-bounds heap read/write here? The function
find_global_var() extracts off and sz from BTF, but off + sz is never
validated against the buffer size vsz before accessing buf + off.
> + goto out;
> + }
> + if (sz == 4)
> + *(__u32 *)(buf + off) = *val;
> + else
> + *(__u64 *)(buf + off) = *val;
> + err = bpf_map__update_elem(map, &zero, sizeof(zero), buf, vsz, 0);
> + if (err)
> + PRINT_FAIL("failed to write '%s': %d\n", name, err);
> +out:
> + free(buf);
> + return err;
> +}
[ ... ]
> @@ -557,6 +708,24 @@ static int parse_test_spec(struct test_loader *tester,
> spec->mode_mask |= UNPRIV;
> spec->unpriv.execute = true;
> has_unpriv_retval = true;
> + } else if ((val = str_has_pfx(s, "test_global_set="))) {
> + err = parse_global_var(val, &spec->priv.set_global_var,
> + &spec->priv.set_global_val,
> + "__set_global");
[Severity: Medium]
Storing the variable in a singular field here also means that using multiple
__set_global() or __ret_global() tags will result in the earlier ones being
ignored. Should this support a list of variables instead?
> + if (err)
> + goto cleanup;
> + spec->priv.has_set_global = true;
> + spec->priv.execute = true;
> + spec->mode_mask |= PRIV;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260926050006.2213110-1-yonghong.song@linux.dev?part=19
next prev parent reply other threads:[~2026-09-26 5:18 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 5:00 [PATCH bpf-next v6 00/21] bpf: Run exception cleanup landing pads when bpf_unwind() unwinds Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 01/21] bpf: Pack bpf_insn_aux_data flags into bit fields Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 02/21] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 03/21] bpf: Add the bpf_unwind() and bpf_unwind_resume() kfuncs Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 04/21] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 05/21] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-09-26 5:16 ` sashiko-bot
2026-09-26 23:54 ` Yonghong Song
2026-09-27 20:39 ` bot+bpf-ci
2026-09-28 0:01 ` Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 06/21] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-26 5:21 ` sashiko-bot
2026-09-27 0:02 ` Yonghong Song
2026-09-27 20:40 ` bot+bpf-ci
2026-09-28 0:12 ` Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 07/21] bpf: Resume a covered call at its landing pad Yonghong Song
2026-09-26 5:15 ` sashiko-bot
2026-09-26 8:21 ` Alexei Starovoitov
2026-09-27 0:04 ` Yonghong Song
2026-09-27 0:41 ` Yonghong Song
2026-09-27 20:40 ` bot+bpf-ci
2026-09-28 0:17 ` Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 08/21] bpf: Refuse a landing pad that does not resume Yonghong Song
2026-09-26 5:17 ` sashiko-bot
2026-09-27 3:06 ` Yonghong Song
2026-09-27 20:40 ` bot+bpf-ci
2026-09-28 0:29 ` Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 09/21] bpf: Refuse a private stack for a program with an exception cleanup table Yonghong Song
2026-09-26 5:00 ` [PATCH bpf-next v6 10/21] bpf: Dispatch cleanup pads by rewriting return addresses Yonghong Song
2026-09-27 20:40 ` bot+bpf-ci
2026-09-28 1:08 ` Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 11/21] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-26 5:15 ` sashiko-bot
2026-09-27 4:35 ` Yonghong Song
2026-09-27 20:39 ` bot+bpf-ci
2026-09-28 3:10 ` Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 12/21] bpf, arm64: " Yonghong Song
2026-09-26 5:14 ` sashiko-bot
2026-09-27 20:40 ` bot+bpf-ci
2026-09-26 5:01 ` [PATCH bpf-next v6 13/21] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 14/21] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 15/21] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-27 20:39 ` bot+bpf-ci
2026-09-28 3:28 ` Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 16/21] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 17/21] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 18/21] selftests/bpf: Add an end-to-end .bpf_cleanup exception test Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 19/21] selftests/bpf: Add __set_global() and __ret_global() test tags Yonghong Song
2026-09-26 5:18 ` sashiko-bot [this message]
2026-09-27 4:58 ` Yonghong Song
2026-09-27 20:24 ` bot+bpf-ci
2026-09-28 3:36 ` Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 20/21] selftests/bpf: Cover the exception cleanup shapes the chain does not reach Yonghong Song
2026-09-27 20:40 ` bot+bpf-ci
2026-09-28 3:49 ` Yonghong Song
2026-09-26 5:01 ` [PATCH bpf-next v6 21/21] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song
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=20260926051839.F28911F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yonghong.song@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.