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

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