Re: [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct

[Andrew Morton]

On Fri,  4 Sep 2026 17:53:33 +0300 Anastasios Papagiannis <tasos.papagiannnis@xxxxxxxxx> wrote:

> On MMU systems, during exec, argument and environment strings are copied
> into the new address space held by struct linux_binprm before that address
> space is installed on the task_struct. Existing BPF user memory helpers
> operate on the current address space or one associated with a task_struct.
> Because no task_struct refers to the new address space at this point,
> programs cannot access these strings from the bprm_check_security LSM
> hook.
> 
> This series adds two sleepable BPF kfuncs for copying bytes or
> NUL-terminated strings from a trusted struct mm_struct. It also marks
> linux_binprm->mm as trusted-or-null, allowing BPF LSM programs to pass it
> to the kfuncs after a NULL check and inspect exec arguments before
> allowing the exec to continue.

Why didn't I get the usual bpfbot review emails for this series?  Is
this a sign that all was clear?

> Changing bprm->mm to trusted-or-null would otherwise reject existing BPF
> programs that read through it without a NULL check. Preserve that behavior
> by allowing fault-protected reads through trusted-or-null BTF pointers.
> Pointer arithmetic, writes, atomic RMW operations, BPF_LOAD_ACQ accesses,
> and passing the pointer to a kfunc that requires a non-NULL trusted
> argument continue to require an explicit NULL check.
> 
> On NOMMU systems, exec argument and environment strings remain in
> bprm->page[] until they are transferred to the new process stack. They
> cannot be accessed through bprm->mm at the bprm_check_security hook.
> The new kfuncs remain available on NOMMU for address ranges represented
> by a supplied struct mm_struct.

I'm surprised that bpf even attempts to support NOMMU.  I expect the
user/tester population is zero.  Perhaps just disallow this, if it
saves any effort.