All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.