UBUNTU-CVE-2026-72292: Medium severity ubuntu/linux-hwe-edge vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In kvm_s390_get_cmma_bits(), allocate the output buffer with vzalloc() instead of vmalloc() so uninitialized gaps are zero-filled.
Event History
Frequently Asked Questions
Who can trigger the information disclosure?
A user space caller that can invoke KVM_S390_GET_CMMA_BITS through KVM on s390 can receive uninitialized kernel-memory bytes. The disclosure occurs in the non-peek migration path when dirty pages have clean or unmapped gaps between them.
What conditions are required for affected bytes to be returned?
The CMMA query must cover a span from a first dirty page to a last dirty page with intervening clean or unmapped pages. Because the walk ignores holes and only writes output for pages with the CMMA dirty bit set, those intervening output bytes can remain uninitialized and are copied to user space.
What mitigation is described if an update cannot be applied immediately?
The provided data does not identify a configuration workaround. Exposure is tied to use of KVM_S390_GET_CMMA_BITS in its non-peek migration path, so avoiding that operation would avoid the described copy of uninitialized buffer gaps.
How does the fix prevent disclosure?
The fix changes allocation from vmalloc() to vzalloc(), causing the output buffer to be zero-initialized. Clean and unmapped gaps in the reported range therefore return zero rather than stale kernel memory.