Linux KernelOperating system · Linux
CVE-2026-53084
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceA lock ordering vulnerability exists in the Linux kernel's BPF task_vma iterator where holding the per-VMA lock across the entire BPF program body creates a problematic lock chain (vm_lock -> i_rwsem -> mmap_lock -> vm_lock). The fix modifies the _next() function to snapshot the VMA via memcpy() while holding the lock, then release the lock before the BPF program accesses the snapshot. The verifier only trusts vm_mm and vm_file pointers, with vm_file reference-counted under the lock.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
Linux KernelOperating system
>= 6.7, < 6.12.91>= 6.13, < 6.18.33>= 6.19, < 7.0.10CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check your running kernel versionRun `uname -r` or `cat /proc/version` to obtain the kernel version stringAffected if The version falls within any of these ranges: >= 6.7 and < 6.12.91; >= 6.13 and < 6.18.33; >= 6.19 and < 7.0.10
-
Verify BPF subsystem is enabledCheck kernel config with `cat /boot/config-$(uname -r) | grep -i bpf` or check if /sys/kernel/debug/tracing/events/bpf/ existsAffected if BPF is loaded and the task_vma iterator functionality is available in the environment
-
Confirm the task_vma iterator is in useInspect loaded BPF programs: run `bpftool prog list` and look for programs using task_vma iterator, or review BPF program source code for references to `bpf_task_vma_iterator`Affected if BPF programs utilizing the task_vma iterator are present and running
-
Check for presence of the vulnerable lock sequence in kernelExamine kernel source code in the BPF subsystem for the task_vma iteration logic; look for code that acquires per-VMA lock then calls BPF helpers requiring mmap_lock without releasing the VMA lock firstAffected if The vulnerable lock ordering pattern (vm_lock -> i_rwsem -> mmap_lock) exists in the running kernel's BPF task_vma implementation
You are affected if your kernel version is within the affected ranges AND BPF programs using the task_vma iterator are in use, allowing the unsafe lock ordering to be triggered.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped6.12.916.18.337.0.10
This is a kernel-level vulnerability requiring a kernel patch. Organizations should apply Linux kernel updates that include this fix when available. There is no userspace-only workaround; systems running untrusted BPF programs are at greatest risk.
Upgrade to kernel 6.12.91 (if on 6.12.x), 6.18.33 (if on 6.13-6.18.x), or 7.0.10 (if on 6.19+), or obtain the equivalent vendor patch
- Identify the running kernel version using `uname -r`
- Check if the version falls within affected ranges: >= 6.7 and < 6.12.91, >= 6.13 and < 6.18.33, or >= 6.19 and < 7.0.10
- If affected, schedule a maintenance window for kernel upgrade
- Obtain the fixed kernel version from your distribution's kernel repository
- For distributions using kernel.org sources: upgrade to 6.12.91+, 6.18.33+, or 7.0.10+ as appropriate for your base version
- For enterprise distributions (RHEL, Ubuntu LTS, etc.): apply vendor-specific kernel update when available
- Reboot into the new kernel and verify the fix is present by checking the kernel version
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Linux Kernel
Scoped from the published advisory
- Consultation2.0 h
- Implementation8.0 h
- Testing6.0 h
- Review / QA4.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,536.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-53084 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-53084 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data