Re: [PATCH bpf-next v9 4/5] bpf: Mark linux_binprm->mm as trusted-or-null

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] bpf: kernel panic via missing PROBE_MEM on fexit of free_bprm
- [High] bpf: ABI breakage on bprm->mm dereference due to TRUSTED_OR_NULL upgrade
--

commit 128aa90c601cd807f8be00c84b4237b6611809e3
Author: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>

bpf: Mark linux_binprm->mm as trusted-or-null

This commit marks linux_binprm->mm as a trusted-or-null nested pointer in the
BPF verifier, allowing BPF programs to pass it to kfuncs after a NULL check.
It also updates an LSM selftest to perform this NULL check before usage.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 6c6b8d8520cdf..3539a768b9211 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6051,6 +6055,7 @@ static bool type_is_trusted_or_null(struct bpf_verifier_env *env,
>  {
>  	BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct socket));
>  	BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct dentry));
> +	BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct linux_binprm));

[Severity: Critical]
Can this upgrade to a trusted pointer cause a kernel panic if a user loads
an fexit program attached to free_bprm()?

Because free_bprm() frees the bprm object before the fexit hook executes,
reading bprm->mm yields a garbage pointer. Before this patch, the verifier
automatically inserted a BPF_PROBE_MEM exception table entry to protect the
dereference of the untrusted pointer.

By upgrading bprm->mm to a PTR_TRUSTED nested pointer, the verifier bypasses
this BPF_PROBE_MEM safety net. If the fexit program checks for NULL and then
dereferences it, could it trigger an unhandled page fault and crash the
system?

>  	BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct vm_area_struct));
>  
>  	return btf_nested_type_is_trusted(&env->log, reg, field_name, btf_id,
> diff --git a/tools/testing/selftests/bpf/progs/lsm.c b/tools/testing/selftests/bpf/progs/lsm.c
> index 7de173daf27b6..7441d66c080c9 100644
> --- a/tools/testing/selftests/bpf/progs/lsm.c
> +++ b/tools/testing/selftests/bpf/progs/lsm.c
> @@ -121,7 +122,9 @@ int BPF_PROG(test_void_hook, struct linux_binprm *bprm)
>  		bprm_count++;
>  
>  	bpf_copy_from_user(args, sizeof(args), (void *)bprm->vma->vm_mm->arg_start);
> -	bpf_copy_from_user(args, sizeof(args), (void *)bprm->mm->arg_start);
> +	mm = bprm->mm;
> +	if (mm)
> +		bpf_copy_from_user(args, sizeof(args), (void *)mm->arg_start);

[Severity: High]
Will this change break ABI compatibility for existing BPF programs?

As this selftest modification demonstrates, existing BPF tracing or LSM
programs that access bprm->mm without a NULL check will now be strictly
rejected at load time by the verifier.

Previously, the pointer was treated as untrusted and the verifier
automatically shielded the dereference with a BPF_PROBE_MEM load, gracefully
handling NULLs at runtime.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918131757.42802-1-tasos.papagiannnis@gmail.com?part=4