CVE-2026-98468
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel bug produced confusing error messages when virtual machines shut down under heavy memory load, but created no real security risk or operational outage.
- Exploitation
- Other
- Attacker needs
- None
- Complexity
- Theoretical
- Impact
- Other
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
A benign race condition between KVM stage-2 page-table teardown and MMU notifier invalidation can cause __unmap_stage2_range to observe a NULL mmu->pgt after a cond_resched_rwlock_write and incorrectly return -EINVAL, triggering a spurious WARN_ON.
Why it matters to the business
Generates misleading kernel warnings during guest exit under memory pressure, increasing log volume and analyst workload with no actual loss of integrity, confidentiality, or availability.
How an attack unfolds
No attacker-controlled exploitation path exists; the race occurs only between legitimate kernel threads (kcompactd/MM U notifier versus kvm_arch_flush_shadow_all) during nested-guest teardown and is handled correctly despite the warning.
How to fix it
Apply the upstream KVM arm64 fix that updates stage2_apply_range to treat concurrent PGT teardown as a non-error condition; rebuild and deploy the patched kernel on all arm64 hosts running KVM.
How to confirm the fix worked
Confirm the patched kernel contains the updated stage2_apply_range logic that no longer calls WARN_ON on -EINVAL from a NULL mmu->pgt after lock contention; reproduce the original test workload (nested guests + compaction) and verify absence of the warning.
How to detect it
Search kernel logs and dmesg for the string "WARNING: arch/arm64/kvm/mmu.c:336 at __unmap_stage2_range" together with kcompactd and mmu_notifier stack traces; correlate with guest exit events under memory pressure.
What your security team should do
- Prioritize patching arm64 KVM hosts within normal maintenance windows given the low EPSS and non-security nature of the bug.
- Suppress or filter the specific arch/arm64/kvm/mmu.c:336 warning in monitoring systems until patches are deployed.
- Review nested-virtualization usage and memory-pressure scenarios in lab environments to confirm the race is no longer triggered.
The record
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix spurious warning for benign stage 2 teardown race kvmtool was used to establish an L1 guest with 8 CPUs and 8 GiB of RAM, an L2 guest with 4 CPUs and 4 GiB of RAM and an L3 guest with 2 CPUs and 2 GiB of RAM, all of which was then exited. Under memory pressure in the L0 host warnings were observed due to migration triggered by compaction: WARNING: arch/arm64/kvm/mmu.c:336 at __unmap_stage2_range+0x64/0x80, CPU#5: kcompactd0/66 Which was, in turn, triggered by an MMU notifier for the host invalidation: mmu_notifier_invalidate_range_start() -> ... -> kvm_mmu_notifier_invalidate_range_start() -> kvm_mmu_unmap_gfn_range() -> kvm_unmap_gfn_range() -> kvm_nested_s2_unmap() -> kvm_stage2_unmap_range() -> __unmap_stage2_range() -> stage2_apply_range() <- -EINVAL, triggering a WARN_ON() Racing with L0's teardown of stage 2 page tables: exit_mm() -> mmput() -> __mmput() -> exit_mmap() -> mmu_notifier_release() -> ... -> kvm_mmu_notifier_release() -> kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd() -> [ acquire kvm->mmu_lock for write ] -> mmu->pgt = NULL [ among other tasks ] -> [ release kvm->mmu_lock for write ] It turns out there is a benign race resulting in a spurious warning: Thread A - notify: migration | Thread B - notify: release -------------------------------|--------------------------------- < kvm->mmu_lock held > | stage2_apply_range() | get mmu->pgt, check !NULL | ... | kvm_arch_flush_shadow_all() cond_resched_rwlock_write(); | < contend, sleep kvm->mmu_lock > < drop kvm->mmu_lock > | < acquire kvm->mmu_lock> | ... | kvm_free_stage2_pgd() | mmu->pgt = NULL | < invalidate MMU > | ... | < release kvm->mmu_lock > [ scheduled ] | stage2_apply_range() | < loop to next > | get, mmu->pgt, check !NULL | is NULL, return -EINVAL | __unmap_stage2_range() | WARN_ON(-EINVAL) <--- entirely spurious - the race was handled correctly. Fix the spurious warning by updating stage2_apply_range() to no longer treat concurrent PGT teardown on lock release as an error - whether the walker is tearing down page tables or doing something else this is a legitimate reason to abort the operation without error. This keeps the warning in place for all other circumstances. In practice only __unmap_stage2_range() actually does anything with the error so this only impacts that.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|