On Sun, May 03, 2026 at 04:13:01PM +0000, [email protected] wrote: > > 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.
Yes, the above is true. The check should occur in bpf_prog_load(), immediately after bpf_check() successfully returns. Kind regards, -- Aaron Tomlin
signature.asc
Description: PGP signature
