<?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://vulnerability.circl.lu</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, 02 Oct 2026 10:51:46 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39928 — i2c: rtl9300: ensure data length is within supported range</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39928</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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://vulnerability.circl.lu/vuln/cve-2025-39928</guid>
    </item>
  </channel>
</rss>
