CVE-2026-53084: Linux kernel · bpf: return VMA snapshot from task_vma iterator
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in 592226d138378601ae28eb890e2bbc23ec3600f7 : update Linux kernel when convenient.
Data as of 6 Nov 2026, 16:34 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
Thin evidence
One scorer or none- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-11-06.
- Patch
- Available – fixed in 592226d138378601ae28eb890e2bbc23ec3600f7, 13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8, 83b8802c034e843b83a3e1ef6f30cdd4e9ec291c +1
Exploitation evidence
Disclosed: evidence found.
CVE published 24 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.
What to do
Upgrade Linux kernel to 592226d138378601ae28eb890e2bbc23ec3600f7, 13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8, 83b8802c034e843b83a3e1ef6f30cdd4e9ec291c or 4cbee026db54cad39c39db4d356100cb133412b3.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: bpf: return VMA snapshot from task_vma iterator Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted.
References
- git.kernel.org/stable/c/83b8802c034e843b83a3e1ef6f30cdd4e9ec291c (opens in a new tab)
- git.kernel.org/stable/c/592226d138378601ae28eb890e2bbc23ec3600f7 (opens in a new tab)
- git.kernel.org/stable/c/13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8 (opens in a new tab)
- git.kernel.org/stable/c/4cbee026db54cad39c39db4d356100cb133412b3 (opens in a new tab)