CVE-2026-98468: KVM: arm64: Fix spurious warning for benign stage 2 teardown race

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 unmapstage2range+0x64/0x80, CPU#5: kcompactd0/66

Which was, in turn, triggered by an MMU notifier for the host invalidation:

mmunotifierinvalidaterangestart() -> ... -> kvmmmunotifierinvalidaterangestart() -> kvmmmuunmapgfnrange() -> kvmunmapgfnrange() -> kvmnesteds2unmap() -> kvmstage2unmaprange() -> unmapstage2range() -> stage2applyrange() <- -EINVAL, triggering a WARNON()

Racing with L0's teardown of stage 2 page tables:

exitmm() -> mmput() -> mmput() -> exitmmap() -> mmunotifierrelease() -> ... -> kvmmmunotifierrelease() -> kvmflushshadowall() -> kvmarchflushshadowall() -> kvmfreestage2pgd() -> [ acquire kvm->mmulock for write ] -> mmu->pgt = NULL [ among other tasks ] -> [ release kvm->mmulock for write ]

It turns out there is a benign race resulting in a spurious warning:

Thread A - notify: migration | Thread B - notify: release -------------------------------|--------------------------------- < kvm->mmulock held > | stage2applyrange() | get mmu->pgt, check !NULL | ... | kvmarchflushshadowall() condreschedrwlockwrite(); | < contend, sleep kvm->mmulock > < drop kvm->mmulock > | < acquire kvm->mmulock> | ... | kvmfreestage2pgd() | mmu->pgt = NULL | < invalidate MMU > | ... | < release kvm->mmulock > [ scheduled ] | stage2applyrange() | < loop to next > | get, mmu->pgt, check !NULL | is NULL, return -EINVAL | unmapstage2range() | WARNON(-EINVAL) <--- entirely spurious - the race was handled correctly.

Fix the spurious warning by updating stage2applyrange() 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 unmapstage2range() actually does anything with the error so this only impacts that.