From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH v2] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
Date: Sun, 03 May 2026 15:54:00 +0000 [thread overview]
Message-ID: <20260503155400.CFE68C2BCB4@smtp.kernel.org> (raw)
In-Reply-To: <20260503153730.541685-1-atomlin@atomlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The kernel is prematurely tainted during the BPF verifier's static analysis phase, causing false-positive taints and potential panics for rejected programs.
--
commit 58605e7e9b9266affb08aa0c20744ecff2dd01d4
Author: Aaron Tomlin <atomlin@atomlin.com>
bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
This commit introduces a new kernel taint flag (TAINT_UNSAFE_BPF) to indicate
when an eBPF program utilizing mutating helpers like bpf_probe_write_user()
or bpf_override_return() is loaded.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 69d75515ed3f..cf0634d8901f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -10287,6 +10287,14 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
> return err;
> }
>
> + /*
> + * Taint the kernel if the program attempts to use mutating
> + * helpers.
> + */
> + if (func_id == BPF_FUNC_probe_write_user ||
> + func_id == BPF_FUNC_override_return)
> + add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
Is it possible for the kernel to be tainted here even if the program is
ultimately rejected by the verifier?
check_helper_call() is executed during the verifier's static analysis phase.
If the program fails verification later (for example, failing the
GPL-compatibility check immediately following this code, or encountering an
invalid memory access), the program is safely rejected and never loaded.
Because add_taint() synchronously modifies global state, wouldn't the kernel
remain permanently tainted in this scenario, falsely indicating a compromised
state?
Furthermore, if panic_on_taint is enabled, could a user trigger a panic
merely by attempting to load a malformed program that contains these helpers?
Could this be addressed by recording the intent to taint within the program's
auxiliary data during verification, and only invoking add_taint() once the
program has successfully passed all checks and is definitively loaded?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260503153730.541685-1-atomlin@atomlin.com?part=1
next prev parent reply other threads:[~2026-05-03 15:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 15:37 [RFC PATCH v2] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers Aaron Tomlin
2026-05-03 15:54 ` sashiko-bot [this message]
2026-05-03 16:13 ` bot+bpf-ci
2026-05-03 16:40 ` Aaron Tomlin
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=20260503155400.CFE68C2BCB4@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atomlin@atomlin.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox