<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T21:46:09.622049+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-74584</id>
    <title>BELL-CVE-2026-74584</title>
    <updated>2026-10-03T21:46:10.475080+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-74584"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1162</id>
    <title>certfr-2026-avi-1162 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
    <updated>2026-10-03T21:46:10.475166+00:00</updated>
    <content>certfr-2026-avi-1162</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-1162"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-358493</id>
    <title>EUVD-2026-358493</title>
    <updated>2026-10-03T21:46:10.475189+00:00</updated>
    <content>EUVD-2026-358493</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-358493"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74584</id>
    <title>fkie_cve-2026-74584</title>
    <updated>2026-10-03T21:46:10.475203+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/bnxt_re: zero shared page before exposing to userspace</p>
<p>bnxt_re_alloc_ucontext() allocates uctx-&gt;shpg via
__get_free_page(GFP_KERNEL). The buddy allocator does not zero pages
without __GFP_ZERO, so the page contains stale kernel data from
whatever object most recently freed it.</p>
<p>The page is then mapped into userspace via vm_insert_page() under
BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes
4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside
bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed
to userspace unsanitised, leaking kernel memory contents.</p>
<p>Any user with access to /dev/infiniband/uverbsX on a host with a
bnxt_re device (typically rdma group membership) can read this data
via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT.</p>
<p>Other shared pages in the same file already use get_zeroed_page()
correctly:</p>
<p>drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);</p>
<p>uctx-&gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-74584"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-j6vr-r53f-g3jf</id>
    <title>GHSA-j6vr-r53f-g3jf</title>
    <updated>2026-10-03T21:46:10.475303+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/bnxt_re: zero shared page before exposing to userspace</p>
<p>bnxt_re_alloc_ucontext() allocates uctx-&gt;shpg via
__get_free_page(GFP_KERNEL). The buddy allocator does not zero pages
without __GFP_ZERO, so the page contains stale kernel data from
whatever object most recently freed it.</p>
<p>The page is then mapped into userspace via vm_insert_page() under
BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes
4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside
bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed
to userspace unsanitised, leaking kernel memory contents.</p>
<p>Any user with access to /dev/infiniband/uverbsX on a host with a
bnxt_re device (typically rdma group membership) can read this data
via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT.</p>
<p>Other shared pages in the same file already use get_zeroed_page()
correctly:</p>
<p>drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);</p>
<p>uctx-&gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-j6vr-r53f-g3jf"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</id>
    <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T21:46:10.475381+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</id>
    <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T21:46:10.475988+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74584</id>
    <title>UBUNTU-CVE-2026-74584</title>
    <updated>2026-10-03T21:46:10.476440+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: zero shared page before exposing to userspace bnxt_re_alloc_ucontext() allocates uctx-&gt;shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it. The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents. Any user with access to /dev/infiniband/uverbsX on a host with a bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT. Other shared pages in the same file already use get_zeroed_page() correctly:   drivers/infiniband/hw/bnxt_re/ib_verbs.c       srq-&gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);       cq-&gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL); uctx-&gt;shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page().</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74584"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</id>
    <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
    <updated>2026-10-03T21:46:10.476798+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970"/>
  </entry>
</feed>
