CVE-2026-98468 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified as KVM arm64 spurious warning for benign stage 2 teardown race involves a concurrency issue within the Kernel-based Virtual Machine subsystem on ARM64 architectures. This flaw manifests when managing nested virtualization scenarios, specifically involving multiple levels of guests such as L1, L2, and L3 configurations under significant memory pressure. The core technical deficiency lies in the handling of page table unmap operations during concurrent teardown sequences. When a host system experiences memory compaction triggered by migration events, it initiates an MMU notifier invalidation sequence that propagates through kvm_mmu_notifier_invalidate_range_start to __unmap_stage2_range. Simultaneously, another thread may be executing the release notification path associated with exiting a virtual machine process, which involves calling exit_mm and subsequently mmput leading to kvm_free_stage2_pgd. These two parallel execution paths contend for the same mutex lock protecting the MMU state of the KVM instance.
The race condition occurs because Thread A holds the mmu_lock while attempting to apply unmap ranges via stage2_apply_range, whereas Thread B contends for and eventually acquires the write lock to flush shadows and free page table descriptors. During this window, Thread A may drop its hold on the lock temporarily due to scheduling or contention resolution mechanisms like cond_resched_rwlock_write. If Thread B completes the teardown sequence by setting mmu->pgt to NULL before Thread A resumes, the subsequent check in stage2_apply_range detects a null pointer and returns an error code of -EINVAL. This return value is then passed up the call stack to __unmap_stage2_range, which interprets this specific outcome as a failure condition rather than a benign race completion. Consequently, the kernel triggers a spurious WARN_ON warning despite the underlying operation being handled correctly by the concurrent teardown logic.
From an operational impact perspective, while this vulnerability does not result in data corruption or privilege escalation, it generates noisy and misleading kernel warnings that can obscure genuine issues during debugging and monitoring. The presence of these false positives complicates system administration tasks where log analysis is critical for maintaining stability. Furthermore, excessive warning output can contribute to performance overhead due to the associated logging mechanisms and potential context switches triggered by the warning infrastructure itself. In high-density virtualization environments or cloud infrastructures running nested guests with large memory footprints, such spurious alerts could lead administrators to incorrectly diagnose system instability or misconfigure resource limits based on erroneous log entries indicating failures where none actually occurred.
The resolution involves modifying stage2_apply_range to recognize that a null page table pointer resulting from concurrent teardown is not an error condition requiring warning generation. By treating this specific race outcome as a legitimate reason to abort the unmap operation without raising flags, the kernel maintains accurate diagnostic fidelity while eliminating false positives. This fix ensures that warnings remain active for actual errors in other circumstances, preserving the integrity of system monitoring tools. To mitigate similar risks and align with industry standards such as CWE-362 which addresses concurrent execution race conditions leading to unintended behavior, administrators should ensure their Linux kernels are updated to include this patch. Additionally, adhering to MITRE ATT&CK techniques related to defense evasion through log manipulation highlights the importance of accurate logging; false warnings can be exploited or simply cause alert fatigue that masks real threats. Regularly applying kernel updates and monitoring for specific warning patterns in /var/log/messages or dmesg output are recommended practices to maintain system health and security posture in virtualized ARM64 environments.