CVE-2026-99178 in Linux
Summary
by MITRE • 10/28/2026
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: <NMI> 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 </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 __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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel contains a critical race condition within the x86 KVM subsystem that can lead to a host system panic when handling asynchronous page faults in non-maskable interrupt contexts. The vulnerability stems from how the kernel manages per-CPU state for async page fault reasons, specifically the apf_reason.flags field. When an asynchronous page not present event is injected into a guest virtual machine, it triggers a #PF vector exception on the host CPU. This event sets flags in the per-CPU structure which are subsequently read and cleared by the __kvm_handle_async_pf function to indicate that the fault has been processed. However, if a Non-Maskable Interrupt arrives after this flag is set but before the original page fault handler clears it, a dangerous race condition occurs. If the NMI handler itself encounters a page fault during its execution, such as when walking user stack frames for performance profiling, it will invoke the same async page fault handling logic. Because interrupts are disabled in NMI context to prevent recursion and ensure atomicity, the nested call to __kvm_handle_async_pf finds that interrupts are already disabled. This state mismatch causes the kernel to trigger a panic with the message Host injected async #PF in interrupt disabled region, effectively crashing the host system hosting the virtual machine.
The operational impact of this vulnerability is severe, resulting in immediate denial of service for all workloads running on the affected physical server. The specific scenario described involves performance monitoring tools like perf sampling hardware cycles and attempting to build user call chains by walking the stack using __get_user. If a saved frame pointer points to an unmapped page or if the walk exceeds valid memory bounds, a page fault occurs within the NMI handler. Since this happens while the host is already processing another async page fault for KVM, the nested handling logic incorrectly attempts to consume flags that belong to the outer context. This issue was originally identified during rework of async PF delivery in 2020 but remained unmerged until now. The vulnerability affects systems running as L1 hypervisors with DELIVERY_AS_PF_VMEXIT enabled, where KVM reads these flags after a VM-exit. Although recent kernel versions have stopped setting KVM_ASYNC_PF_SEND_ALWAYS for user mode faults, the race window persists for specific edge cases involving NMI context page faults, allowing an attacker or even benign high-load performance profiling to trigger the crash.
Mitigation requires applying the upstream Linux kernel patch that modifies the __kvm_handle_async_pf function to check if interrupts are disabled before consuming async #PF flags. If interrupts are found to be disabled, indicating the code is running in NMI context and has interrupted a previous handler, the function returns immediately without touching the apf_reason.flags. This ensures that the original page fault handler retains its state integrity when it resumes execution after the NMI completes. For administrators unable to apply kernel updates immediately, reducing the frequency of performance profiling with user call chains or avoiding frame pointer walks over unmapped pages can reduce the likelihood of triggering the nested page fault within an NMI. However, given that this is a fundamental race condition in interrupt handling logic, upgrading to a patched kernel version remains the only reliable remediation strategy to prevent host panics under heavy virtualization and profiling loads.