<?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>Sun, 04 Oct 2026 01:38:09 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12248</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12248</link>
      <description>bdu:2026-12248</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12248</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31649</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31649</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-31649</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0526 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</link>
      <description>certfr-2026-avi-0526</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</guid>
    </item>
    <item>
      <title>EUVD-2026-364765</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364765</link>
      <description>EUVD-2026-364765</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364765</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31649</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31649</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: stmmac: fix integer underflow in chain mode&lt;/p&gt;
&lt;p&gt;The jumbo_frm() chain-mode implementation unconditionally computes&lt;/p&gt;
&lt;p&gt;len = nopaged_len - bmax;&lt;/p&gt;
&lt;p&gt;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is
BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit()
decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including
page fragments):&lt;/p&gt;
&lt;p&gt;is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc);&lt;/p&gt;
&lt;p&gt;When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a
large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the
subtraction wraps as an unsigned integer, producing a huge len value
(~0xFFFFxxxx).  This causes the while (len != 0) loop to execute
hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i
pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less
SoCs (the typical deployment for stmmac), this maps arbitrary kernel
memory to the DMA engine, constituting a kernel memory disclosure and
potential memory corruption from hardware.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a buf_len local variable clamped to
min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then
always safe: it is zero when the linear portion fits within a single
descriptor, causing the while (len != 0) loop to be skipped naturally,
and the fragment loop in stmmac_xmit() handles page fragments afterward.&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;net: stmmac: fix integer underflow in chain mode&lt;/p&gt;
&lt;p&gt;The jumbo_frm() chain-mode implementation unconditionally computes&lt;/p&gt;
&lt;p&gt;len = nopaged_len - bmax;&lt;/p&gt;
&lt;p&gt;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is
BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit()
decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including
page fragments):&lt;/p&gt;
&lt;p&gt;is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc);&lt;/p&gt;
&lt;p&gt;When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a
large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the
subtraction wraps as an unsigned integer, producing a huge len value
(~0xFFFFxxxx).  This causes the while (len != 0) loop to execute
hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i
pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less
SoCs (the typical deployment for stmmac), this maps arbitrary kernel
memory to the DMA engine, constituting a kernel memory disclosure and
potential memory corruption from hardware.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a buf_len local variable clamped to
min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then
always safe: it is zero when the linear portion fits within a single
descriptor, causing the while (len != 0) loop to be skipped naturally,
and the fragment loop in stmmac_xmit() handles page fragments afterward.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31649</guid>
    </item>
    <item>
      <title>GHSA-jv6m-v86w-343p</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-jv6m-v86w-343p</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: stmmac: fix integer underflow in chain mode&lt;/p&gt;
&lt;p&gt;The jumbo_frm() chain-mode implementation unconditionally computes&lt;/p&gt;
&lt;p&gt;len = nopaged_len - bmax;&lt;/p&gt;
&lt;p&gt;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is
BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit()
decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including
page fragments):&lt;/p&gt;
&lt;p&gt;is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc);&lt;/p&gt;
&lt;p&gt;When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a
large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the
subtraction wraps as an unsigned integer, producing a huge len value
(~0xFFFFxxxx).  This causes the while (len != 0) loop to execute
hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i
pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less
SoCs (the typical deployment for stmmac), this maps arbitrary kernel
memory to the DMA engine, constituting a kernel memory disclosure and
potential memory corruption from hardware.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a buf_len local variable clamped to
min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then
always safe: it is zero when the linear portion fits within a single
descriptor, causing the while (len != 0) loop to be skipped naturally,
and the fragment loop in stmmac_xmit() handles page fragments afterward.&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;net: stmmac: fix integer underflow in chain mode&lt;/p&gt;
&lt;p&gt;The jumbo_frm() chain-mode implementation unconditionally computes&lt;/p&gt;
&lt;p&gt;len = nopaged_len - bmax;&lt;/p&gt;
&lt;p&gt;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is
BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit()
decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including
page fragments):&lt;/p&gt;
&lt;p&gt;is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc);&lt;/p&gt;
&lt;p&gt;When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a
large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the
subtraction wraps as an unsigned integer, producing a huge len value
(~0xFFFFxxxx).  This causes the while (len != 0) loop to execute
hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i
pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less
SoCs (the typical deployment for stmmac), this maps arbitrary kernel
memory to the DMA engine, constituting a kernel memory disclosure and
potential memory corruption from hardware.&lt;/p&gt;
&lt;p&gt;Fix this by introducing a buf_len local variable clamped to
min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then
always safe: it is zero when the linear portion fits within a single
descriptor, causing the while (len != 0) loop to be skipped naturally,
and the fragment loop in stmmac_xmit() handles page fragments afterward.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-jv6m-v86w-343p</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31649 — net: stmmac: fix integer underflow in chain mode</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31649</link>
      <description>msrc_CVE-2026-31649</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31649</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-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:20826-1</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:2068-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:2068-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:2068-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31649</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31649</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes     len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including page fragments):     is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc); When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx).  This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes     len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB.  However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb-&amp;gt;len (total length including page fragments):     is_jumbo = stmmac_is_jumbo_frm(priv, skb-&amp;gt;len, enh_desc); When a packet has a small linear portion (nopaged_len &amp;lt;= bmax) but a large total length due to page fragments (skb-&amp;gt;len &amp;gt; bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx).  This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb-&amp;gt;data + bmax * i pointers far beyond the skb buffer to dma_map_single().  On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax).  Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31649</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1279 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</guid>
    </item>
  </channel>
</rss>
