<?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 22:49:54 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74390</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74390</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-74390</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1231 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1231</link>
      <description>certfr-2026-avi-1231</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1231</guid>
    </item>
    <item>
      <title>EUVD-2026-354205</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-354205</link>
      <description>EUVD-2026-354205</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-354205</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74390</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74390</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs&lt;/p&gt;
&lt;p&gt;The irdma_copy_user_pgaddrs function loops through all of the umem DMA
blocks to populate the PBLEs and will stop when either the last DMA
block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that
the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero
values.&lt;/p&gt;
&lt;p&gt;When irdma_setup_pbles is called with lvl==0, it
calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means
the only way to break out of the loop is to reach the last umem DMA
block, which means it could end up going beyond the fixed size of 4
iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case.&lt;/p&gt;
&lt;p&gt;In the case of QP/CQ/SRQ rings, the value of lvl is determined by a
separate input (for example, req.cq_pages in the case of a CQ). So,
we must perform explicit checking to ensure we don&amp;#39;t overflow the
pgaddrmem array if the user provides a umem that consists of more
blocks than their provided req.cq_pages.&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/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs&lt;/p&gt;
&lt;p&gt;The irdma_copy_user_pgaddrs function loops through all of the umem DMA
blocks to populate the PBLEs and will stop when either the last DMA
block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that
the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero
values.&lt;/p&gt;
&lt;p&gt;When irdma_setup_pbles is called with lvl==0, it
calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means
the only way to break out of the loop is to reach the last umem DMA
block, which means it could end up going beyond the fixed size of 4
iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case.&lt;/p&gt;
&lt;p&gt;In the case of QP/CQ/SRQ rings, the value of lvl is determined by a
separate input (for example, req.cq_pages in the case of a CQ). So,
we must perform explicit checking to ensure we don&amp;#39;t overflow the
pgaddrmem array if the user provides a umem that consists of more
blocks than their provided req.cq_pages.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74390</guid>
    </item>
    <item>
      <title>GHSA-c23v-2w7h-h6m9</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c23v-2w7h-h6m9</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs&lt;/p&gt;
&lt;p&gt;The irdma_copy_user_pgaddrs function loops through all of the umem DMA
blocks to populate the PBLEs and will stop when either the last DMA
block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that
the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero
values.&lt;/p&gt;
&lt;p&gt;When irdma_setup_pbles is called with lvl==0, it
calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means
the only way to break out of the loop is to reach the last umem DMA
block, which means it could end up going beyond the fixed size of 4
iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case.&lt;/p&gt;
&lt;p&gt;In the case of QP/CQ/SRQ rings, the value of lvl is determined by a
separate input (for example, req.cq_pages in the case of a CQ). So,
we must perform explicit checking to ensure we don&amp;#39;t overflow the
pgaddrmem array if the user provides a umem that consists of more
blocks than their provided req.cq_pages.&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/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs&lt;/p&gt;
&lt;p&gt;The irdma_copy_user_pgaddrs function loops through all of the umem DMA
blocks to populate the PBLEs and will stop when either the last DMA
block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that
the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero
values.&lt;/p&gt;
&lt;p&gt;When irdma_setup_pbles is called with lvl==0, it
calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means
the only way to break out of the loop is to reach the last umem DMA
block, which means it could end up going beyond the fixed size of 4
iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case.&lt;/p&gt;
&lt;p&gt;In the case of QP/CQ/SRQ rings, the value of lvl is determined by a
separate input (for example, req.cq_pages in the case of a CQ). So,
we must perform explicit checking to ensure we don&amp;#39;t overflow the
pgaddrmem array if the user provides a umem that consists of more
blocks than their provided req.cq_pages.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c23v-2w7h-h6m9</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:23881-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23881-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:23881-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74390</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74390</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 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don&amp;#39;t overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.&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 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc-&amp;gt;total_cnt is reached. The issue is that the logic for checking palloc-&amp;gt;total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc-&amp;gt;total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr-&amp;gt;pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don&amp;#39;t overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74390</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>
