CVE-2026-89919: KVM: s390: keyop: use mmu_lock to read gmap->asce
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: keyop: use mmulock to read gmap->asce
Every other dat consumer in this file (kvms390getskeys, setskeys, getcmmabits, setcmmabits, MEMCLRCMMA, kvms390fixupprefix, kvmtestagegfn, kvmagegfn) reads kvm->arch.gmap->asce inside the mmulock read-side. keyop is the only outlier.
gmap->asce is mutated under writelock(mmulock) by gmapsetlimit() and keyop might use a stale asce value for walking as KVMS390KEYOP and KVMS390VMMEMLIMITSIZE can run concurrently. This can result in memory corruption.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Update KVM s390 keyop so it reads kvm->arch.gmap->asce inside the mmu_lock read-side, consistent with the other dat_* consumers, preventing stale ASCE reads while gmap_set_limit() mutates it under the mmu_lock write lock.
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The race requires KVM s390 key operations and changes to the VM memory limit to run concurrently. In that situation, keyop can use a stale gmap->asce value while walking memory.
What is the potential impact?
The stale address-space-control element can lead to memory corruption. The provided information does not specify a privilege boundary, attack vector, or more detailed exploit impact.
How can I determine whether a system is exposed?
Systems using KVM on s390 are relevant, particularly where KVM_S390_KEYOP operations may overlap with KVM_S390_VM_MEM_LIMIT_SIZE changes. The issue concerns kernel behavior during that concurrent activity; no affected version range is provided.
What should be done if patching cannot happen immediately?
Avoid concurrent use of KVM s390 key operations and VM memory-limit changes where operationally possible. The resolved fix reads gmap->asce under the mmu_lock read-side lock.