CVE-2026-99178: x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context
In the Linux kernel, the following vulnerability has been resolved:
x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context
An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apfreason.flags until kvmhandleasyncpf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics:
Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: <NMI> panic+0x52/0x60 kvmhandleasyncpf+0xb0/0xb0 excpagefault+0x71/0xb0 asmexcpagefault+0x27/0x30 RIP: 0010:getusernocheck8+0x6/0x20 perfcallchainuser+0x147/0x1a0 getperfcallchain+0x12d/0x1c0 ... perfeventnmihandler+0x26/0x50 excnmi+0xe8/0x110 RIP: 0010:asmexcpagefault+0x0/0x30 </NMI>
The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with getuser(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERYASPFVMEXIT, reads the flags itself after a #PF VM-exit.
The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged.
Since that rework, Linux has stopped setting KVMASYNCPFSENDALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact.
Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvmasyncpfnotpresent events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it.