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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: ABI breakage by marking linux_binprm->mm as PTR_MAYBE_NULL
--

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

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

This commit marks the linux_binprm->mm field as a trusted-or-null nested
pointer so it can be passed to kfuncs after a NULL check. It updates the
existing LSM selftest to reflect this new verifier requirement.

> 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
> @@ -5997,6 +5997,10 @@ BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct dentry) {
>  	struct inode *d_inode;
>  };
>  
> +BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct linux_binprm) {
> +	struct mm_struct *mm;
> +};
> +

[Severity: Critical]
Will this cause an ABI regression for existing BPF programs? 

Before this patch, the bprm->mm field was treated as an untrusted pointer
(PTR_TO_BTF_ID | PTR_UNTRUSTED). The verifier permits dereferencing untrusted
pointers without a NULL check by safely rewriting these accesses to use
BPF_PROBE_MEM exception tables.

By explicitly adding it to the BTF_TYPE_SAFE_TRUSTED_OR_NULL list, the
verifier now tags it with PTR_MAYBE_NULL. The verifier strictly forbids any
direct dereference on a PTR_MAYBE_NULL pointer before an explicit NULL check.

Does this change mean that previously valid, safe BPF programs will now be
rejected at load time, violating the kernel's UAPI backward compatibility
guarantee?

To avoid this breakage while still allowing kfunc usage, could a kfunc
accessor be exposed (such as bpf_bprm_get_mm()) instead of modifying the BTF
property of the struct field?

> 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: Critical]
This selftest modification appears to demonstrate the regression in 
test_void_hook. Doesn't this prove that existing BPF programs in the wild
that access bprm->mm without a NULL check are no longer accepted by the
verifier?

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