> diff --git a/Documentation/admin-guide/tainted-kernels.rst
> b/Documentation/admin-guide/tainted-kernels.rst
[ ... ]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 11054ad89c14..e2060c6f3e13 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -9906,6 +9906,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?
> /* eBPF programs must be GPL compatible to use GPL-ed functions */
> if (!env->prog->gpl_compatible && fn->gpl_only) {
> verbose(env, "cannot call GPL-restricted function from non-GPL
> compatible program\n");
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25283723455
