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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Premature kernel tainting in bpf_prog_load() before the program is fully loaded and exposed.
--

commit b04c8335f7a6d97d5ae1eb32256b36d77ac00d40
Author: Aaron Tomlin <atomlin@atomlin.com>

bpf: introduce TAINT_UNSAFE_BPF for mutating helpers

This patch introduces a new kernel taint flag (TAINT_UNSAFE_BPF / "V") to
indicate when an eBPF program utilizing destructive or mutating helpers is
loaded.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c

[ ... ]

> @@ -3083,6 +3083,13 @@ static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, u32 uattr_size)
>  	if (err < 0)
>  		goto free_used_maps;
>  
> +	/*
> +	 * The program has passed the verifier. If it utilises unsafe
> +	 * helpers, formally taint the kernel now.
> +	 */
> +	if (prog->aux->taints_kernel)
> +		add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
> +
>  	err = bpf_prog_mark_insn_arrays_ready(prog);
>  	if (err < 0)
>  		goto free_used_maps;

Is it possible for the kernel to be tainted prematurely here?

If bpf_prog_mark_insn_arrays_ready() or bpf_prog_alloc_id() fail, the BPF
program load is aborted, the program is freed, and it is never exposed to
user space or executed. Consequently, the kernel's execution flow and memory
could not have been compromised by the program.

Should the add_taint() call be deferred until after bpf_prog_alloc_id()
completes successfully, which is the point where the program is actually
exposed and cannot be gone underneath us?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260503164700.548164-1-atomlin@atomlin.com?part=1