CVE-2026-99178

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 apf reason.flags until kvm handle async pf() 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: panic+0x52/0x60 kvm handle async pf+0xb0/0xb0 exc page fault+0x71/0xb0 asm exc page fault+0x27/0x30 RIP: 0010: get user nocheck 8+0x6/0x20 perf callchain user+0x147/0x1a0 get perf callchain+0x12d/0x1c0 ... perf event nmi handler+0x26/0x50 exc nmi+0xe8/0x110 RIP: 0010:asm exc page fault+0x0/0x30

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 get user(), 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 DELIVERY AS PF VMEXIT, 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 KVM ASYNC PF SEND ALWAYS, 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 kvm async pf not present 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.