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

[bot+bpf-ci]

> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index e791ae065c39..77f90b887bf1 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c

[ ... ]

> @@ -765,14 +775,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);
                         ^^^^^^^^

sashiko-bot@xxxxxxxxxx raised a concern about this in v4: bpf_find_vma()
traverses the VMA tree of an external mm_struct (from a foreign task) without
checking check_stable_address_space(mm).

When inspecting a foreign task, the mm_struct could be flagged with
MMF_UNSTABLE if it was subject to an OOM reap or a dup_mmap() failure. In this
state, the maple tree can contain XA_ZERO_ENTRY markers.

If find_vma() returns one of these markers, could the subsequent check using
vma->vm_start dereference an internal integer value and cause a kernel panic?

>
> @@ -782,6 +816,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)
> +		bpf_iter_mmput_async(mm);
>  	return ret;
>  }


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27250036662