In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: keyop: use mmu_lock to read gmap->asce
Every other dat_ consumer in this file (kvm_s390_get_skeys,
set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA,
kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads
kvm->arch.gmap->asce inside* the mmu_lock read-side. keyop is the only
outlier.
gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit()
and keyop might use a stale asce value for walking as KVM_S390_KEYOP
and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result
in memory corruption.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - Triggered by KVM_S390_KEYOP and KVM_SET_DEVICE_ATTR(KVM_S390_VM_MEM_LIMIT_SIZE) ioctls on a VM fd from /dev/kvm. Not reachable via network packets or guest instruction emulation.
AC:L - The attacker controls both sides of the race by issuing KEYOP and MEM_LIMIT_SIZE concurrently on a VM they created (before vCPUs exist). No victim state or other uncontrolled condition is required.
PR:L - Regular (non-ucontrol) VM creation has no capability check; any user who can open /dev/kvm, typically via kvm-group membership, can create a VM and issue these ioctls. CAP_SYS_ADMIN is not required.
UI:N - The attacker issues the ioctls on a VM they created; no separate user action is required.
S:U - This is host-userspace-to-host-kernel memory corruption via KVM ioctls, not a guest-to-host escape. MEM_LIMIT_SIZE is rejected once vCPUs exist, and guest storage-key paths already read gmap->asce under mmu_lock.
C:H - kvm_s390_keyop snapshots gmap->asce without mmu_lock while gmap_set_limit() can free that CRST under write_lock, a page-table use-after-free. Walking reused tables, including ISKE/page_get_storage_key, can disclose kernel memory.
I:H - SSKE walks the stale ASCE with DAT_WALK_ALLOC and writes via page_set_storage_key and pgste updates. The use-after-free of gmap tables enables writes into recycled kernel memory and storage-key changes on attacker-chosen physical pages.
A:H - Walking freed CRST/PTE memory or spinning on PGSTE locks derived from reused pages can oops, panic, or hang the host kernel.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - Triggered by KVM_S390_KEYOP and KVM_SET_DEVICE_ATTR(KVM_S390_VM_MEM_LIMIT_SIZE) ioctls on a VM fd from /dev/kvm. Not reachable via network packets or guest instruction emulation.
AC:L - The attacker controls both sides of the race by issuing KEYOP and MEM_LIMIT_SIZE concurrently on a VM they created (before vCPUs exist). No victim state or other uncontrolled condition is required.
PR:L - Regular (non-ucontrol) VM creation has no capability check; any user who can open /dev/kvm, typically via kvm-group membership, can create a VM and issue these ioctls. CAP_SYS_ADMIN is not required.
UI:N - The attacker issues the ioctls on a VM they created; no separate user action is required.
S:U - This is host-userspace-to-host-kernel memory corruption via KVM ioctls, not a guest-to-host escape. MEM_LIMIT_SIZE is rejected once vCPUs exist, and guest storage-key paths already read gmap->asce under mmu_lock.
C:H - kvm_s390_keyop snapshots gmap->asce without mmu_lock while gmap_set_limit() can free that CRST under write_lock, a page-table use-after-free. Walking reused tables, including ISKE/page_get_storage_key, can disclose kernel memory.
I:H - SSKE walks the stale ASCE with DAT_WALK_ALLOC and writes via page_set_storage_key and pgste updates. The use-after-free of gmap tables enables writes into recycled kernel memory and storage-key changes on attacker-chosen physical pages.
A:H - Walking freed CRST/PTE memory or spinning on PGSTE locks derived from reused pages can oops, panic, or hang the host kernel.
CVSS 3.1