bpf: return VMA snapshot from task_vma iterator
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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.91, 6.18.33, 7.0.10
- CVEs
- CVE-2026-53084
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 12:43 UTC · Revision 1
Source evidence
bpf: return VMA snapshot from task_vma iterator
core-osv · Original sourcePublished 24 Jun 2026, 16:30 UTC
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.
osv:CVE-2026-53084
Kernel
Fixed versions: 6.12.91, 6.18.33, 7.0.10
Complete source record
{
"id": "6975c0f5c9b3a3462b1e4e616065db89858e8afe7c5298aac56e8cb7b0c4ddfb",
"url": "https://osv.dev/vulnerability/CVE-2026-53084",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "bpf: return VMA snapshot from task_vma iterator",
"summary": "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.",
"evidence": "osv:CVE-2026-53084",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.12.91",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.33",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.10",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-53084",
"aliases": [
"CVE-2026-53084"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "4ac4546821584736798aaa9e97da9f6eaf689ea3"
},
{
"fixed": "83b8802c034e843b83a3e1ef6f30cdd4e9ec291c"
},
{
"fixed": "592226d138378601ae28eb890e2bbc23ec3600f7"
},
{
"fixed": "13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8"
},
{
"fixed": "4cbee026db54cad39c39db4d356100cb133412b3"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53084.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.91"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.33"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.0.10"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53084.json"
}
}
],
"modified": "2026-10-28T02:30:28.938945043Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8",
"https://git.kernel.org/stable/c/4cbee026db54cad39c39db4d356100cb133412b3",
"https://git.kernel.org/stable/c/592226d138378601ae28eb890e2bbc23ec3600f7",
"https://git.kernel.org/stable/c/83b8802c034e843b83a3e1ef6f30cdd4e9ec291c",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53084.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-53084",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53084.json"
}
},
"related_cves": [
{
"value": "CVE-2026-53084",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 495537,
"published_at": "2026-06-24T16:30:24.356+00:00"
}