CVE-2026-93137: bpf: Fix use-after-free on mm_struct in bpf_find_vma()
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix use-after-free on mmstruct in bpffindvma()
bpffindvma() reads task->mm and calls mmapreadtrylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exitmm() can free the mmstruct between the lockless read and the trylock, resulting in a use-after-free. mmstruct is not SLABTYPESAFEBYRCU.
For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloclock and release it with mmputasync(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded taskvma iterator"). Use spintrylock() instead of gettaskmm() so BPF context does not block on alloclock. Reject irqs-disabled contexts and !CONFIGMMU on the foreign-task path because dropping the mm reference is not safe there.
Race:
CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpffindvma(foreigntask): mm = task->mm exitmm(): task->mm = NULL mmput(mm) -> frees mmstruct mmapreadtrylock(mm) // UAF on mm
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (bpf: Fix use-after-free on mm_struct in bpf_find_vma)to a version that resolves this vulnerability.Patch d8e27d2d22b6 - Configuration
Ensure CONFIG_MMU is enabled, since the fix addresses rejecting !CONFIG_MMU (irqs-disabled contexts) for this issue.
Linux kernel CONFIG_MMU = enabled
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A BPF program must call bpf_find_vma() for a foreign task while that task concurrently exits and releases its mm_struct. The race occurs between the lockless read of task->mm and mmap_read_trylock(mm).
Is the current task affected by this race?
No. The data states that task->mm is stable when bpf_find_vma() is used on the current task; the vulnerable path concerns foreign tasks.
Are all execution contexts able to use the corrected foreign-task path?
No. The fix rejects foreign-task use when interrupts are disabled and when the kernel is built without CONFIG_MMU, because safely dropping the mm reference is not possible in those cases.