[PATCH bpf-next v5] bpf: Fix use-after-free on mm_struct in bpf_find_vma()

[PATCH bpf-next v5] bpf: Fix use-after-free on mm_struct in bpf_find_vma()

[Sanghyun Park]

bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without
holding a reference on the mm. On a foreign task, a concurrent exit_mm()
can free the mm_struct between the lockless read and the trylock,
resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU.

For the current task, task->mm is stable. For a foreign task, pin the mm
under task->alloc_lock and release it with mmput_async(), mirroring commit
d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator").
Use spin_trylock() instead of get_task_mm() so BPF context does not block
on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the
foreign-task path because dropping the mm reference is not safe there.

Race:

  CPU0 (BPF program)                  CPU1 (exiting task)
  ============================        ==========================
  bpf_find_vma(foreign_task):
    mm = task->mm
                                      exit_mm():
                                        task->mm = NULL
                                        mmput(mm) -> frees mm_struct
    mmap_read_trylock(mm)
        // UAF on mm

Fixes: 7c7e3d31e785 ("bpf: Introduce helper bpf_find_vma")
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Sanghyun Park <sanghyun.park.cnu@gmail.com>
---
v5:
 - Replace bpf_iter_mmput_async() with mmput_async() directly as suggested
   by Yonghong.
 - Add Yonghong's Acked-by.
v4: https://lore.kernel.org/bpf/20260610024637.343364-1-sanghyun.park.cnu@gmail.com/
 - Use [PATCH bpf-next] subject as requested by Alexei.
 - Add the missing BPF maintainers/reviewers to Cc.
v3: https://lore.kernel.org/bpf/20260609105216.3536839-1-sanghyun.park.cnu@gmail.com/
 - Drop get_task_mm()+mmput(); mirror d8e27d2d22b6 with alloc_lock
   trylock + mmput_async(). (Yonghong Song)
 - Reject irqs-disabled contexts on the foreign-task path.
 - Reject foreign-task path when !CONFIG_MMU: bpf_iter_mmput_async()
   falls back to mmput() which may sleep, and bpf_find_vma() can run
   in non-sleepable context.
 - Shorten the foreign-task rationale comment and trim the changelog body.
 - Fix the v2's whitespace damage.
v2: https://lore.kernel.org/bpf/CAOrxSK5_7e4114VyfEU9htGi+UneuNt88fGVKOAa3_ZenPOFkA@mail.gmail.com/

 kernel/bpf/task_iter.c | 43 ++++++++++++++++++++++++++++++------------
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
index e791ae065c39b..27ceead874651 100644
--- a/kernel/bpf/task_iter.c
+++ b/kernel/bpf/task_iter.c
@@ -756,6 +756,7 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,
 	struct mmap_unlock_irq_work *work = NULL;
 	struct vm_area_struct *vma;
 	bool irq_work_busy = false;
+	bool mmput_needed = false;
 	struct mm_struct *mm;
 	int ret = -ENOENT;
 
@@ -765,14 +766,38 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,
 	if (!task)
 		return -ENOENT;
 
-	mm = task->mm;
+	if (task == current) {
+		mm = task->mm;
+	} else {
+		/*
+		 * Foreign task: pin task->mm against a concurrent exit_mm().
+		 * Use trylock on alloc_lock instead of get_task_mm()'s
+		 * blocking task_lock() to avoid deadlocking the target task.
+		 */
+		if (!IS_ENABLED(CONFIG_MMU))
+			return -EOPNOTSUPP;
+		if (irqs_disabled())
+			return -EBUSY;
+		if (!spin_trylock(&task->alloc_lock))
+			return -EBUSY;
+		mm = task->mm;
+		if (mm && !(task->flags & PF_KTHREAD)) {
+			mmget(mm);
+			mmput_needed = true;
+		} else {
+			mm = NULL;
+		}
+		spin_unlock(&task->alloc_lock);
+	}
 	if (!mm)
 		return -ENOENT;
 
 	irq_work_busy = bpf_mmap_unlock_get_irq_work(&work);
 
-	if (irq_work_busy || !mmap_read_trylock(mm))
-		return -EBUSY;
+	if (irq_work_busy || !mmap_read_trylock(mm)) {
+		ret = -EBUSY;
+		goto out;
+	}
 
 	vma = find_vma(mm, start);
 
@@ -782,6 +807,9 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,
 		ret = 0;
 	}
 	bpf_mmap_unlock_mm(work, mm);
+out:
+	if (mmput_needed)
+		mmput_async(mm);
 	return ret;
 }
 
@@ -796,15 +824,6 @@ const struct bpf_func_proto bpf_find_vma_proto = {
 	.arg5_type	= ARG_ANYTHING,
 };
 
-static inline void bpf_iter_mmput_async(struct mm_struct *mm)
-{
-#ifdef CONFIG_MMU
-	mmput_async(mm);
-#else
-	mmput(mm);
-#endif
-}
-
 struct bpf_iter_task_vma_kern_data {
 	struct task_struct *task;
 	struct mm_struct *mm;
-- 
2.48.1

Re: [PATCH bpf-next v5] bpf: Fix use-after-free on mm_struct in bpf_find_vma()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The patch removes the `bpf_iter_mmput_async()` helper function but leaves an active call to it in `bpf_iter_task_vma_destroy()`, causing an unconditional compilation failure.
- [Low] Calling `mmput_async()` directly causes a build failure on configurations without `CONFIG_MMU` and `CONFIG_FUTEX_PRIVATE_HASH`.
--

commit 2e44c7b3855fc202fcf8df33fd8efe7bae06e921
Author: Sanghyun Park <sanghyun.park.cnu@gmail.com>
Subject: bpf: Fix use-after-free on mm_struct in bpf_find_vma()

This commit addresses a use-after-free in bpf_find_vma() by safely
pinning task->mm for foreign tasks under alloc_lock. It adds a required
mmput_async() call on the exit path and removes the static inline wrapper
bpf_iter_mmput_async().

> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index e791ae065c39b..27ceead874651 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c

[ ... ]

> @@ -782,6 +807,9 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,
>  		ret = 0;
>  	}
>  	bpf_mmap_unlock_mm(work, mm);
> +out:
> +	if (mmput_needed)
> +		mmput_async(mm);

[Severity: Low]
Does directly invoking mmput_async() break the build on configurations
without CONFIG_MMU?

The removed bpf_iter_mmput_async() wrapper previously fell back to mmput()
when CONFIG_MMU was disabled. Even though this new path is guarded by a
runtime IS_ENABLED(CONFIG_MMU) check earlier in the function, the C compiler
still evaluates the function call, which might be undeclared in the headers
on !CONFIG_MMU builds.

>  	return ret;
>  }
>  
> @@ -796,15 +824,6 @@ const struct bpf_func_proto bpf_find_vma_proto = {
>  	.arg5_type	= ARG_ANYTHING,
>  };
>  
> -static inline void bpf_iter_mmput_async(struct mm_struct *mm)
> -{
> -#ifdef CONFIG_MMU
> -	mmput_async(mm);
> -#else
> -	mmput(mm);
> -#endif
> -}
> -

[Severity: Low]
Does the removal of bpf_iter_mmput_async() cause a build failure?

While the wrapper was removed here, it looks like it is still being called
further down in the file:

kernel/bpf/task_iter.c:bpf_iter_task_vma_destroy() {
        ...
        if (kit->data) {
                bpf_iter_task_vma_snapshot_reset(&kit->data->snapshot);
                put_task_struct(kit->data->task);
                bpf_iter_mmput_async(kit->data->mm);
                ...
        }
}

Will this cause an undeclared identifier error when compiling
bpf_iter_task_vma_destroy()?

>  struct bpf_iter_task_vma_kern_data {
>  	struct task_struct *task;
>  	struct mm_struct *mm;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630023443.3026627-2-sanghyun.park.cnu@gmail.com?part=1

[syzbot ci] Re: bpf: Fix use-after-free on mm_struct in bpf_find_vma()

[syzbot ci]

syzbot ci has tested the following series

[v5] bpf: Fix use-after-free on mm_struct in bpf_find_vma()
https://lore.kernel.org/all/20260630023443.3026627-2-sanghyun.park.cnu@gmail.com
* [PATCH bpf-next v5] bpf: Fix use-after-free on mm_struct in bpf_find_vma()

and found the following issue:
kernel build error

Full report is available here:
https://ci.syzbot.org/series/f0ce67c9-2c09-418c-bbe2-c698246e9c7f

***

kernel build error

tree:      bpf-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git
base:      53435562a725962e4de0c29653223129ba11643a
arch:      amd64
compiler:  Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config:    https://ci.syzbot.org/builds/a434cf48-2810-46a3-bb75-064be88b96be/config

kernel/bpf/task_iter.c:1017:3: error: call to undeclared function 'bpf_iter_mmput_async'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).

The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.