Linux Kernel KVM kvm_s390_get_cmma_bits uninitialized pointer

Summaryinfo

A vulnerability was found in Linux Kernel and classified as problematic. The impacted element is the function kvm_s390_get_cmma_bits of the component KVM. Such manipulation leads to uninitialized pointer. This vulnerability is documented as CVE-2026-72292. The attack needs to be performed locally. There is not any exploit available.

Detailsinfo

A vulnerability was found in Linux Kernel (the affected version is unknown). It has been rated as problematic. Affected by this issue is the function kvm_s390_get_cmma_bits of the component KVM. The manipulation with an unknown input leads to a uninitialized pointer vulnerability. Using CWE to declare the problem leads to CWE-824. The product accesses or uses a pointer that has not been initialized. Impacted is confidentiality. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2026-72292 since 08/09/2026. The exploitation is known to be easy. The attack needs to be approached locally. There are known technical details, but no exploit is available.

Applying the patch a4a19941ccb2164edc3491faa5ac5df82e94b363 is able to eliminate this problem.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion