<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 15:51:11 +0000</lastBuildDate>
    <item>
      <title>Withdrawn: BELL-CVE-2026-72292 — CVE-2026-72292 does not affect BellSoft software</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-72292</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-72292</guid>
    </item>
    <item>
      <title>EUVD-2026-353729</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353729</link>
      <description>EUVD-2026-353729</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353729</guid>
    </item>
    <item>
      <title>fkie_cve-2026-72292</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72292</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory&lt;/p&gt;
&lt;p&gt;kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:&lt;/p&gt;
&lt;p&gt;values = vmalloc(args-&amp;gt;count);&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Use vzalloc() so the gaps read back as zero.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory&lt;/p&gt;
&lt;p&gt;kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:&lt;/p&gt;
&lt;p&gt;values = vmalloc(args-&amp;gt;count);&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Use vzalloc() so the gaps read back as zero.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-72292</guid>
    </item>
    <item>
      <title>GHSA-g39r-65h4-wx32</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g39r-65h4-wx32</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory&lt;/p&gt;
&lt;p&gt;kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:&lt;/p&gt;
&lt;p&gt;values = vmalloc(args-&amp;gt;count);&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Use vzalloc() so the gaps read back as zero.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory&lt;/p&gt;
&lt;p&gt;kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:&lt;/p&gt;
&lt;p&gt;values = vmalloc(args-&amp;gt;count);&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Use vzalloc() so the gaps read back as zero.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g39r-65h4-wx32</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-72292</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72292</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 115 more&lt;/p&gt;
&lt;p&gt;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-&amp;gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 115 more&lt;/p&gt;
&lt;p&gt;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-&amp;gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72292</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
