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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Pre-existing race condition between concurrent NMIs and HW IRQs leading to a leaked mmap_read_trylock() in bpf_find_vma().
--

commit 4672ecd9d6bd9a98e0de397e206fa5c87190b657
Author: Sanghyun Park <sanghyun.park.cnu@gmail.com>

bpf: Fix use-after-free on mm_struct in bpf_find_vma()
    
This commit fixes a use-after-free on mm_struct in bpf_find_vma() by pinning
the mm_struct via task->alloc_lock for foreign tasks. It introduces a trylock
and mmput_async() path to safely handle the mm lifecycle when interacting
with tasks other than current.

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

[ ... ]

> @@ -765,14 +766,38 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,

[ ... ]

>  	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,11 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, task, u64, start,
>  		ret = 0;
>  	}
>  	bpf_mmap_unlock_mm(work, mm);

[Severity: High]
This isn't a bug introduced by this patch, but could a race condition between
concurrent NMIs and hardware IRQs leak the mmap read lock here?

If a hardware IRQ calls bpf_find_vma(), it fetches the per-CPU
mmap_unlock_irq_work structure via bpf_mmap_unlock_get_irq_work(). If an NMI
interrupts execution before bpf_mmap_unlock_mm() is called and queues the
work, an NMI tracing program could also call bpf_find_vma().

Because irqs_disabled() is true in the NMI, it fetches the exact same per-CPU
work structure. The NMI would successfully acquire mmap_read_trylock(), set
work->mm to its mm, queue the work, and return.

When the hardware IRQ resumes, it takes its own mmap_read_trylock(), calls
bpf_mmap_unlock_mm(), overwrites work->mm with the hardware IRQ's mm, and
attempts to queue the already-pending work. When the irq_work later executes,
it only drops the lock for the hardware IRQ's mm, permanently leaking the
read lock for the NMI's mm.

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