CVE-2026-72292: KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Initialize KVMS390GETCMMABITS memory
kvms390getcmmabits() allocates its output buffer with vmalloc(), which does not zero the returned pages:
values = vmalloc(args->count);
In the non-peek (migration) path, datgetcmma() reports a byte count spanning from the first to the last dirty page, but datgetcmmapte() writes values[gfn - start] only for pages whose CMMA dirty bit is set. The walk uses DATWALKIGNHOLES, so clean and unmapped pages that lie between two dirty pages within the reported span are visited but never store their byte. Those gaps (up to KVMS390MAXBITDISTANCE pages each) stay uninitialized yet fall inside [0, count) and are copied out by copytouser(), disclosing stale kernel memory to user space.
Before the switch to the new gmap implementation the buffer was fully populated for every gfn in the span, so no uninitialized bytes were exposed; the dirty-only walk introduced the leak.
Use vzalloc() so the gaps read back as zero.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the KVM_S390_GET_CMMA_BITS path for s390, initialize the output buffer: allocate with vzalloc() (instead of vmalloc()) so any uninitialized gaps between dirty pages are returned to user space as zero and do not leak stale kernel memory.
KVM on s390 (Linux kernel) Initialize KVM_S390_GET_CMMA_BITS memory (use vzalloc for vmalloc-backed output buffer) = Allocate output buffer with vzalloc() instead of vmalloc() so gaps/uninitialized pages read back as zero