Re: [PATCH bpf-next v6 2/5] exec: Clear bprm->mm before dropping its reference

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch clears `bprm->mm` to prevent a BPF Use-After-Free, but misses `bprm->file`, which is also explicitly marked as a trusted pointer by the BPF verifier and is left dangling.
--

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

exec: Clear bprm->mm before dropping its reference

The patch ensures that once mmput() drops the final reference to bprm->mm,
the pointer is no longer accessible through struct linux_binprm. This prevents
BPF kfuncs from accessing a freed mm_struct.

> diff --git a/fs/exec.c b/fs/exec.c
> index 745f6eb5279e6..4ddd403fd91c7 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
[ ... ]
> @@ -1456,9 +1456,12 @@ void bprm_drop_loader(struct linux_binprm *bprm)
>  
>  static void free_bprm(struct linux_binprm *bprm)
>  {
> -	if (bprm->mm) {
> +	struct mm_struct *mm = bprm->mm;
> +
> +	if (mm) {
>  		acct_arg_size(bprm, 0);
> -		mmput(bprm->mm);
> +		bprm->mm = NULL;
> +		mmput(mm);
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but while attempting to fix the BPF
use-after-free for bprm->mm, could this leave a dangling pointer in bprm->file
further down in free_bprm()?

In free_bprm(), the reference to bprm->file is dropped, but the pointer is not
cleared:

    static void free_bprm(struct linux_binprm *bprm)
    {
        ...
        do_close_execat(bprm->file);
        /* An unconsumed PT_INTERP substitute from a binfmt_misc loader entry. */
        bprm_drop_loader(bprm);
        ...
    }

Immediately after, the globally visible bprm_drop_loader(bprm) is called.
If a BPF fentry tracing program is attached to bprm_drop_loader, it receives
bprm as a trusted argument. Since the BPF verifier explicitly marks
bprm->file as BTF_TYPE_SAFE_TRUSTED, this exposes the stale pointer to the
tracing program as a trusted argument.

This could allow a use-after-free or direct memory load of a freed struct
file if the program passes this dangling pointer to kfuncs requiring a trusted
struct file *.

Would it be safer to also clear bprm->file after closing it here, similar to
how bprm->mm is being handled?

Note that fields like cred, user_ns, and old_mm do not have this issue because
they are not marked as trusted by the verifier and are treated as untrusted
PTR_TO_BTF_ID pointers.

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