CVE-2026-89919 Overview
CVE-2026-89919 is a race condition in the Linux kernel's KVM subsystem for the IBM s390 architecture. The flaw resides in the keyop handler, which reads kvm->arch.gmap->asce without holding the mmu_lock. Every other dat_* consumer in the same file performs this read inside the mmu_lock read-side. Because gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit(), concurrent execution of KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can cause keyop to walk memory using a stale address-space control element (ASCE). The result is potential memory corruption on the host.
Critical Impact
A local attacker with access to KVM ioctls on an s390 host can trigger memory corruption by racing key operations against memory limit changes.
Affected Products
- Linux kernel KVM subsystem on the s390 (IBM Z) architecture
- Distributions shipping affected Linux kernel versions with KVM/s390 support
- Systems exposing KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE ioctls to guests or unprivileged VMMs
Discovery Timeline
- 2026-09-16 - CVE-2026-89919 published to NVD
- 2026-09-16 - Last updated in NVD database
Technical Details for CVE-2026-89919
Vulnerability Analysis
The vulnerability is a race condition [CWE-362] in the s390 KVM guest address translation path. The keyop code path handles storage key operations on guest memory and must translate guest addresses using the guest mapping (gmap) structure. Translation relies on the ASCE stored in kvm->arch.gmap->asce. This field is not immutable; it can be updated when the memory limit changes.
Correct consumers such as kvm_s390_get_skeys, kvm_s390_set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, and kvm_age_gfn acquire mmu_lock for reading before dereferencing gmap->asce. The keyop handler omitted this lock acquisition, breaking the synchronization invariant used elsewhere in the file.
Root Cause
The root cause is missing lock coverage around a shared, mutable field. gmap_set_limit() takes mmu_lock for writing when it swaps the ASCE. Any reader must therefore hold mmu_lock for reading to observe a coherent value. The keyop path read gmap->asce outside the lock, allowing the compiler and CPU to observe a torn or stale value while the writer replaces it.
Attack Vector
Exploitation requires local access with permission to invoke KVM ioctls, typically a VMM process or a privileged guest interface. The attacker issues KVM_S390_KEYOP calls concurrently with KVM_S390_VM_MEM_LIMIT_SIZE operations that change the memory limit. When keyop walks page tables using a stale ASCE, translation can resolve to memory outside the intended guest mapping, leading to host memory corruption. The fix moves the gmap->asce read inside the mmu_lock read-side, aligning keyop with the other dat_* consumers.
No public proof-of-concept code has been released. Technical details are available in the upstream commits referenced by the Kernel Git Commit Log and the companion stable backport commit.
Detection Methods for CVE-2026-89919
Indicators of Compromise
- Unexpected kernel oops, general protection faults, or paging exceptions on s390 hosts running KVM guests
- Guest memory contents appearing in unrelated host or guest processes after storage-key operations
- Kernel log entries referencing gmap, asce, or KVM s390 translation errors around the time of concurrent memory-limit changes
Detection Strategies
- Inventory s390 hosts and compare running kernel versions against the fixed commits ae452b990e05 and da07a751efa4.
- Audit which workloads issue KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE ioctls, since exploitation requires both to run concurrently.
- Correlate KVM guest crashes with host-side kernel warnings to identify possible triggering activity.
Monitoring Recommendations
- Forward kernel logs from s390 KVM hosts to a centralized logging or SIEM platform for anomaly review.
- Monitor process launches and ioctl activity from VMM processes such as qemu-system-s390x for unusual call patterns.
- Alert on repeated host kernel panics or guest instability that coincide with memory hotplug or limit-change operations.
How to Mitigate CVE-2026-89919
Immediate Actions Required
- Apply the upstream Linux kernel fix that acquires mmu_lock before reading gmap->asce in the s390 keyop handler.
- Update to distribution kernel packages that include commits ae452b990e05 and da07a751efa4.
- Restrict access to KVM ioctls on s390 hosts to trusted VMM processes only.
Patch Information
The fix is available in the mainline and stable Linux kernel trees. Refer to the upstream commit at the Kernel Git Commit Log and the stable backport. Rebuild or install vendor kernel packages that incorporate these commits, then reboot affected hosts.
Workarounds
- Avoid issuing KVM_S390_VM_MEM_LIMIT_SIZE operations while guests are actively performing storage-key operations.
- Limit exposure of KVM management interfaces to unprivileged users and untrusted tenants on s390 hosts.
- Where patching must be delayed, migrate sensitive workloads off unpatched s390 KVM hosts.
# Verify running kernel version and check for the fix
uname -r
rpm -q --changelog kernel | grep -E 'ae452b990e05|da07a751efa4'
# Debian/Ubuntu equivalent
dpkg -s linux-image-$(uname -r) | grep -i version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

