Re: [RFC PATCH v2] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

> 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