<?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>Fri, 09 Oct 2026 07:28:11 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-04493</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-04493</link>
      <description>bdu:2026-04493</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-04493</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39928</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39928</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-39928</guid>
    </item>
    <item>
      <title>EUVD-2026-347253</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347253</link>
      <description>EUVD-2026-347253</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347253</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39928</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39928</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i2c: rtl9300: ensure data length is within supported range&lt;/p&gt;
&lt;p&gt;Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;
to ensure the data length isn&amp;#39;t within the supported range. In
particular a data length of 0 is not supported by the hardware and
causes unintended or destructive behaviour.&lt;/p&gt;
&lt;p&gt;This limitation becomes obvious when looking at the register
documentation [1]. 4 bits are reserved for DATA_WIDTH and the value
of these 4 bits is used as N + 1, allowing a data length range of
1 &amp;lt;= len &amp;lt;= 16.&lt;/p&gt;
&lt;p&gt;Affected by this is the SMBus Quick Operation which works with a data
length of 0. Passing 0 as the length causes an underflow of the value
due to:&lt;/p&gt;
&lt;p&gt;(len - 1) &amp;amp; 0xf&lt;/p&gt;
&lt;p&gt;and effectively specifying a transfer length of 16 via the registers.
This causes a 16-byte write operation instead of a Quick Write. For
example, on SFP modules without write-protected EEPROM this soft-bricks
them by overwriting some initial bytes.&lt;/p&gt;
&lt;p&gt;For completeness, also add a quirk for the zero length.&lt;/p&gt;
&lt;p&gt;[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&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;i2c: rtl9300: ensure data length is within supported range&lt;/p&gt;
&lt;p&gt;Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;
to ensure the data length isn&amp;#39;t within the supported range. In
particular a data length of 0 is not supported by the hardware and
causes unintended or destructive behaviour.&lt;/p&gt;
&lt;p&gt;This limitation becomes obvious when looking at the register
documentation [1]. 4 bits are reserved for DATA_WIDTH and the value
of these 4 bits is used as N + 1, allowing a data length range of
1 &amp;lt;= len &amp;lt;= 16.&lt;/p&gt;
&lt;p&gt;Affected by this is the SMBus Quick Operation which works with a data
length of 0. Passing 0 as the length causes an underflow of the value
due to:&lt;/p&gt;
&lt;p&gt;(len - 1) &amp;amp; 0xf&lt;/p&gt;
&lt;p&gt;and effectively specifying a transfer length of 16 via the registers.
This causes a 16-byte write operation instead of a Quick Write. For
example, on SFP modules without write-protected EEPROM this soft-bricks
them by overwriting some initial bytes.&lt;/p&gt;
&lt;p&gt;For completeness, also add a quirk for the zero length.&lt;/p&gt;
&lt;p&gt;[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39928</guid>
    </item>
    <item>
      <title>GHSA-m43q-hvcx-4pxc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-m43q-hvcx-4pxc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i2c: rtl9300: ensure data length is within supported range&lt;/p&gt;
&lt;p&gt;Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;
to ensure the data length isn&amp;#39;t within the supported range. In
particular a data length of 0 is not supported by the hardware and
causes unintended or destructive behaviour.&lt;/p&gt;
&lt;p&gt;This limitation becomes obvious when looking at the register
documentation [1]. 4 bits are reserved for DATA_WIDTH and the value
of these 4 bits is used as N + 1, allowing a data length range of
1 &amp;lt;= len &amp;lt;= 16.&lt;/p&gt;
&lt;p&gt;Affected by this is the SMBus Quick Operation which works with a data
length of 0. Passing 0 as the length causes an underflow of the value
due to:&lt;/p&gt;
&lt;p&gt;(len - 1) &amp;amp; 0xf&lt;/p&gt;
&lt;p&gt;and effectively specifying a transfer length of 16 via the registers.
This causes a 16-byte write operation instead of a Quick Write. For
example, on SFP modules without write-protected EEPROM this soft-bricks
them by overwriting some initial bytes.&lt;/p&gt;
&lt;p&gt;For completeness, also add a quirk for the zero length.&lt;/p&gt;
&lt;p&gt;[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&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;i2c: rtl9300: ensure data length is within supported range&lt;/p&gt;
&lt;p&gt;Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39;
to ensure the data length isn&amp;#39;t within the supported range. In
particular a data length of 0 is not supported by the hardware and
causes unintended or destructive behaviour.&lt;/p&gt;
&lt;p&gt;This limitation becomes obvious when looking at the register
documentation [1]. 4 bits are reserved for DATA_WIDTH and the value
of these 4 bits is used as N + 1, allowing a data length range of
1 &amp;lt;= len &amp;lt;= 16.&lt;/p&gt;
&lt;p&gt;Affected by this is the SMBus Quick Operation which works with a data
length of 0. Passing 0 as the length causes an underflow of the value
due to:&lt;/p&gt;
&lt;p&gt;(len - 1) &amp;amp; 0xf&lt;/p&gt;
&lt;p&gt;and effectively specifying a transfer length of 16 via the registers.
This causes a 16-byte write operation instead of a Quick Write. For
example, on SFP modules without write-protected EEPROM this soft-bricks
them by overwriting some initial bytes.&lt;/p&gt;
&lt;p&gt;For completeness, also add a quirk for the zero length.&lt;/p&gt;
&lt;p&gt;[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-m43q-hvcx-4pxc</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39928</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39928</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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39; to ensure the data length isn&amp;#39;t within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour. This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 &amp;lt;= len &amp;lt;= 16. Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to: (len - 1) &amp;amp; 0xf and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes. For completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check for the xfer length to &amp;#39;rtl9300_i2c_config_xfer&amp;#39; to ensure the data length isn&amp;#39;t within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour. This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 &amp;lt;= len &amp;lt;= 16. Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to: (len - 1) &amp;amp; 0xf and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes. For completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39928</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2170 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2170</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen, möglicherweise um beliebigen Code auszuführen oder eine Speicherbeschädigung zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen, möglicherweise um beliebigen Code auszuführen oder eine Speicherbeschädigung zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2170</guid>
    </item>
  </channel>
</rss>
