<?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 16:26:27 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74584</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74584</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-74584</guid>
    </item>
    <item>
      <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>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1162</link>
      <description>certfr-2026-avi-1162</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1162</guid>
    </item>
    <item>
      <title>EUVD-2026-358493</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-358493</link>
      <description>EUVD-2026-358493</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-358493</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74584</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74584</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/bnxt_re: zero shared page before exposing to userspace&lt;/p&gt;
&lt;p&gt;bnxt_re_alloc_ucontext() allocates uctx-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Other shared pages in the same file already use get_zeroed_page()
correctly:&lt;/p&gt;
&lt;p&gt;drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);&lt;/p&gt;
&lt;p&gt;uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().&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;RDMA/bnxt_re: zero shared page before exposing to userspace&lt;/p&gt;
&lt;p&gt;bnxt_re_alloc_ucontext() allocates uctx-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Other shared pages in the same file already use get_zeroed_page()
correctly:&lt;/p&gt;
&lt;p&gt;drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);&lt;/p&gt;
&lt;p&gt;uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74584</guid>
    </item>
    <item>
      <title>GHSA-j6vr-r53f-g3jf</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j6vr-r53f-g3jf</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/bnxt_re: zero shared page before exposing to userspace&lt;/p&gt;
&lt;p&gt;bnxt_re_alloc_ucontext() allocates uctx-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Other shared pages in the same file already use get_zeroed_page()
correctly:&lt;/p&gt;
&lt;p&gt;drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);&lt;/p&gt;
&lt;p&gt;uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().&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;RDMA/bnxt_re: zero shared page before exposing to userspace&lt;/p&gt;
&lt;p&gt;bnxt_re_alloc_ucontext() allocates uctx-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Other shared pages in the same file already use get_zeroed_page()
correctly:&lt;/p&gt;
&lt;p&gt;drivers/infiniband/hw/bnxt_re/ib_verbs.c
      srq-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);
      cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL);&lt;/p&gt;
&lt;p&gt;uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing
convention by switching to get_zeroed_page().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j6vr-r53f-g3jf</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74584</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74584</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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-&amp;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-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);       cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL); uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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-&amp;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-&amp;gt;uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL);       cq-&amp;gt;uctx_cq_page  = (void *)get_zeroed_page(GFP_KERNEL); uctx-&amp;gt;shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74584</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</guid>
    </item>
  </channel>
</rss>
