UBUNTU-CVE-2026-99178: Medium severity vulnerability
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.
Event History
Frequently Asked Questions
What conditions make a system realistically exposed to this issue?
The described failure requires KVM asynchronous page-fault handling, an async page-fault event pending in per-CPU state, and an NMI that itself triggers a page fault before the original page-fault handler consumes the async-PF flags. The example path involves perf sampling with user call chains, where the NMI handler accesses user stack memory.
What is the practical impact if the race is triggered?
The kernel can panic because the NMI-context page fault consumes flags intended for the interrupted async page fault and then detects that it interrupted a region with interrupts disabled. The reported outcome is a host kernel panic rather than a described privilege-escalation or data-disclosure condition.
How can I investigate whether a crash matches this vulnerability?
Check panic logs and call traces for "Host injected async #PF in interrupt disabled region" and for functions such as __kvm_handle_async_pf, exc_page_fault, perf_event_nmi_handler, perf_callchain_user, or __get_user_nocheck_8. A trace showing an NMI landing in the page-fault entry path is also consistent with the described race.