Description
In the Linux kernel, the following vulnerability has been resolved:

KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory

kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:

values = vmalloc(args->count);

In the non-peek (migration) path, dat_get_cmma() reports a byte count
spanning from the first to the last dirty page, but __dat_get_cmma_pte()
writes values[gfn - start] only for pages whose CMMA dirty bit is set.
The walk uses DAT_WALK_IGN_HOLES, 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 KVM_S390_MAX_BIT_DISTANCE pages
each) stay uninitialized yet fall inside [0, count) and are copied out
by copy_to_user(), 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.
Published: 2026-08-15
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Uninitialized memory in the KVM S390 function kvm_s390_get_cmma_bits() allows the kernel to return stale data on the KVM interface. The returned buffer is allocated with vmalloc, which does not zero memory, and only pages marked as dirty are written. Gaps in the span remain uninitialized, and a copy_to_user() operation copies these gaps back to user space, exposing parts of kernel memory. The primary impact is that an attacker can read portions of kernel memory, potentially revealing sensitive data and enabling further attacks such as privilege escalation or data exfiltration.

Affected Systems

This issue affects Linux kernel implementations that include the KVM S390 module, specifically the kvm_s390_get_cmma_bits() implementation. All affected users of Linux kernel running the KVM driver on the s390 architecture are potentially vulnerable, regardless of distribution, provided the module is loaded.

Risk and Exploitability

The vulnerability is local, requiring access to the KVM interface (typically through /dev/kvm). The EPSS score is < 1% and the vulnerability is not listed in the CISA KEV catalog, suggesting it has not yet been widely exploited in the wild. The risk hinges on the presence of a privileged KVM user who can invoke the offending ioctl. The CVSS score of 5.5 indicates a moderate disclosure risk, but the information disclosure is significant enough to warrant immediate remediation, especially in environments where kernel memory confidentiality is critical.

Generated by OpenCVE AI on August 17, 2026 at 16:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that patches kvm_s390_get_cmma_bits to use vzalloc, which zeroes allocated memory
  • If a kernel update is not immediately available, restrict access to /dev/kvm so that only trusted users or services can invoke KVM ioctl calls
  • Consider disabling or unloading the kvm-s390 module when KVM is not needed in the environment

Generated by OpenCVE AI on August 17, 2026 at 16:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 17 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-908
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sat, 15 Aug 2026 11:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-112

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(), which does not zero the returned pages: values = vmalloc(args->count); In the non-peek (migration) path, dat_get_cmma() reports a byte count spanning from the first to the last dirty page, but __dat_get_cmma_pte() writes values[gfn - start] only for pages whose CMMA dirty bit is set. The walk uses DAT_WALK_IGN_HOLES, 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 KVM_S390_MAX_BIT_DISTANCE pages each) stay uninitialized yet fall inside [0, count) and are copied out by copy_to_user(), 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.
Title KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:11:54.937Z

Reserved: 2026-08-09T03:40:39.917Z

Link: CVE-2026-72292

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:22:01.377

Modified: 2026-08-17T06:18:32.017

Link: CVE-2026-72292

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72292 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-17T17:00:05Z

Weaknesses
  • CWE-112

    Missing XML Validation

  • CWE-908

    Use of Uninitialized Resource