Cloudanix VulnDB

CVE-2026-99178

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem inside the Linux kernel's virtual-machine support can cause the whole system to crash suddenly when certain performance tools and memory-handling features are active at the same time.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in KVM async page fault handling where an NMI-context kernel page fault consumes per-CPU async PF reason flags before the interrupted #PF handler can read them, causing a panic when interrupts-disabled state is later detected.

Why it matters to the business

Unexpected kernel panics on Linux hosts or guests running KVM with performance sampling or userfaultfd-backed memory can produce sudden downtime and loss of availability in virtualized workloads.

How an attack unfolds

An attacker with the ability to trigger NMIs while a guest is under memory pressure (async PF events pending) and while perf records user call chains can force the race; the NMI handler's own page fault clears the flags, the original handler then panics on the unexpected disabled-interrupt state.

How to fix it

Update to a Linux kernel containing the fix that returns early without touching async PF flags on kernel-mode faults in NMI context; rebuild and reboot affected hosts and guests.

How to confirm the fix worked

Confirm the patch is present by inspecting the x86/kvm async PF handling code for the early-return condition on kernel #PF in NMI; re-run the described perf-plus-userfaultfd stress test and verify absence of the panic string.

Typical attack path

  1. Trigger async PF delivery into a guest via memory pressure or userfaultfd
  2. Schedule an NMI (perf sampling or other) that lands between async PF injection and flag consumption
  3. Force the NMI handler to take a kernel page fault (e.g., walking unmapped user stack frames)
  4. Observe resulting host or guest panic

How to detect it

Search kernel logs and crash dumps for the exact panic message and the listed call trace involving __kvm_handle_async_pf and perf_event_nmi_handler; correlate with KVM async PF event counters and NMI activity.

What your security team should do

  • Prioritize patching KVM hosts that expose guests to perf-based profiling or demand-paged memory
  • Monitor for the panic string "Host injected async #PF in interrupt disabled region" in kernel logs
  • Temporarily disable perf user call-chain sampling in high-risk KVM environments until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed