Look up another CVE · open CVE-2026-93137 in the interactive tracker
CVE-2026-93137
bpf: Fix use-after-free on mm_struct in bpf_find_vma()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem kernel/bpf. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93137 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/bpf/task_iter.c
- What this is
- BPF [ITERATOR]MAINTAINERS section matched on kernel/bpf/*iter.c · bpf@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel/bpf
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.17 | 6.1.188 | db347840d6b6 |
| 5.17 | 6.6.157 | 8e1101fc4118 |
| 5.17 | 6.12.110 | c7ad910e9870 |
| 5.17 | 6.18.52 | 86d54cf069fc |
| 5.17 | 7.2.6 | 2b2a903bee56 |
| 5.17 | 7.3 | 47b079e2117a |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- bpf_find_vma() is invoked only from a program loaded via bpf(BPF_PROG_LOAD): BPF_PROG_TYPE_SYSCALL (syscall_prog_func_proto) or tracing/raw_tp (bpf_tracing_func_proto), both reaching bpf_base_func_proto() for BPF_FUNC_find_vma. The stale mm comes from bpf_task_from_pid() or a tracing task argument, not from a remote protocol field.
- AC:LAttack complexity, low
- The race is inside bpf_find_vma() between the lockless task->mm load and mmap_read_trylock(mm). The attacker forks a child, looks it up with bpf_task_from_pid(), and hammers BPF_PROG_RUN (or an attached raw_tp) while that child exits so exit_mm()→mmput() frees the mm; they control both sides.
- PR:LPrivileges required, low
- bpf_base_func_proto() returns bpf_find_vma_proto only after bpf_token_capable(CAP_PERFMON); bpf_prog_load() also needs CAP_BPF, and RAW_TRACEPOINT/TRACING fail is_perfmon_prog_type() without CAP_PERFMON. bpf_token_capable() uses ns_capable() on a delegated token's userns, so this is not init-namespace root.
- UI:NUser interaction, none
- The attacker loads the program with BPF_PROG_LOAD, runs it via BPF_PROG_RUN or their own attached probe, and exits their own child so exit_mm() races bpf_find_vma(); no other user must mount a filesystem or open a file.
- S:UScope, unchanged
- mmap_read_trylock() and find_vma() operate on the host kernel mm_struct that bpf_find_vma() cached from task->mm. That is in-kernel memory corruption in the same authority as the bpf() caller, not a KVM/Xen guest-to-host or IOMMU escape.
- C:HConfidentiality impact, high
- After exit_mm() mmput() frees the mm_struct (mm_cachep is not SLAB_TYPESAFE_BY_RCU), bpf_find_vma() still calls find_vma(mm, start) and hands the resulting vm_area_struct to the BPF callback, so the program can read reallocated kernel VMA/mm memory.
- I:HIntegrity impact, high
- The stale mm is used by mmap_read_trylock() (down_read_trylock on mm->mmap_lock) and bpf_mmap_unlock_mm(); those write a freed mm_struct, and find_vma() may walk a reallocated maple tree, which is UAF corruption exploitable for an arbitrary kernel write.
- A:HAvailability impact, high
- down_read_trylock on a freed mm->mmap_lock or find_vma() walking a freed mm->mm_mt oopses or panics the kernel, and the attacker can repeat bpf_find_vma() against children they exit.