KVM SEV: unlocked set_page_dirty on get_user_pages_fast pages during guest memory population

Impact

sev_gmem_post_populate() calls set_page_dirty() on pages obtained from get_user_pages_fast() without holding a lock that pins the page's mapping, so the mapping can go away concurrently and the dirty-marking operates on freed state. This is host-side kernel memory corruption reachable while setting up an SEV or SEV-SNP guest, on exactly the confidential-computing path operators enable to isolate tenant workloads. On a GPU host running confidential VMs it undermines the host kernel that is supposed to be the isolation boundary. The fix switches to set_page_dirty_lock(); the window is narrow and requires the ability to launch SEV guests.

Who can reach it

Local on the hypervisor host: a process able to launch or configure an SEV/SEV-SNP guest through /dev/kvm - normally the VMM service account, not an ordinary tenant. Authentication is required in the sense that the attacker must already hold KVM guest-creation rights.

What to do

Update to a kernel containing the set_page_dirty_lock() fix (two stable commits, tagged for stable) and reboot each SEV-capable host; a KVM module reload is not sufficient in practice on a node running guests, so drain and reboot. Until then, restricting who can create SEV guests limits reachability. No microcode or firmware change is involved.

References

Related entries

• Linux kernel io_uring/waitid: repeated failed cancellations wrap the reference counter and double-complete a requestCVE-2026-99227 · Linux kernel io_uring waitid (31-bit cancel reference counter wrap)High
• Linux kernel io_uring/waitid: use-after-free when the wake handler clears ->head before owning the requestCVE-2026-99231 · Linux kernel io_uring waitid (use-after-free via ->head cleared before ownership)High
• Linux kernel sched_ext: DSQ consume and move paths operate on a task still being dispatchedCVE-2026-99269 · Linux kernel sched_ext (DSQ consume/move racing SCX_OPSS_DISPATCHING)High
• xrdp: out-of-bounds read parsing Confirm Active PDU crashes the server or leaks process memoryCVE-2026-33516 · xrdp (RDP capability exchange, Confirm Active PDU parsing)High
• Linux kernel virtio-gpu: unvalidated EDID block offset lets a malicious backend read past a kernel bufferCVE-2026-68255 · Linux kernel drm/virtio (virtio_get_edid_block response bounds)High
• Linux kernel (drivers/pci): The option-ROM parser trusts the header and data-structure offsets it reads out of theCVE-2026-72487 · Linux kernel (drivers/pci)High