Linux kernel (virt/kvm): The dirty-ring reset path bounds-checks an offset with unchecked 64-bit arithmetic, so a

CVSS 8.0CVE-2026-52969Kernel, userspace & hypervisorcurated

Impact

The dirty-ring reset path bounds-checks an offset with unchecked 64-bit arithmetic, so a crafted pair of ring entries wraps the sum past the check. KVM then indexes the memslot's rmap array with a near-U64_MAX GFN - an out-of-bounds load followed by a conditional bit clear through whatever pointer that load produced. That is an attacker-influenced write into host kernel memory and a straight path to root on the node.

Who can reach it

The commit states it plainly: reachable from any process holding /dev/kvm. The dirty ring is mapped MAP_SHARED into the process, so it rewrites the slot/offset payload of queued entries and then calls KVM_RESET_DIRTY_RINGS. Needs the legacy/shadow MMU path (shadow paging, any VM that allocated shadow roots, or a write-tracked slot). Relevant wherever tenants can open /dev/kvm - nested-virt-enabled VMs, or bare-metal tenants with KVM exposed.

What to do

Update to a kernel carrying the referenced stable commits. Interim: do not expose /dev/kvm to tenant containers, and disable nested virtualization for tenant VMs so guests cannot run their own KVM.

References

https://git.kernel.org/stable/c/74f1a22f7a80f03d28ad8551a2d25d563433addf https://git.kernel.org/stable/c/0eb281eb95b2d4eea4db1da5fe91023aecc97095 https://nvd.nist.gov/vuln/detail/CVE-2026-52969

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.