CVE-2025-39928: i2c: rtl9300: ensure data length is within supported range
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 'rtl9300_i2c_config_xfer'
to ensure the data length isn'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 <= len <= 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) & 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
Security readout for executives and security teams
Plain-English summary
A Linux RTL9300 I2C driver flaw can turn an unsupported zero-length request into a 16-byte write. On devices such as SFP modules with writable EEPROM, this may overwrite configuration data and make the module unusable. Exploitation requires local, low-privileged access; no confidentiality impact is identified.
Executive priority
Prioritize affected network or embedded systems controlling valuable or difficult-to-replace modules. The flaw is not remotely exploitable according to the supplied CVSS data, but successful triggering can corrupt hardware configuration and cause operational outages. Patch during the next urgent maintenance window; accelerate where writable SFP EEPROM and accessible local interfaces coexist.
Technical view
The RTL9300 transfer configuration accepted a zero length although hardware supports only 1–16 bytes. The calculation `(len - 1) & 0xf` underflows for zero and programs a 16-byte transfer. An SMBus Quick Write can therefore become an unintended 16-byte write. The kernel fix adds explicit length validation and a zero-length quirk.
Likely exposure
Exposure is limited to Linux systems using the RTL9300 I2C controller driver where local users or software can initiate affected SMBus operations. Risk is greatest when attached components, including SFP modules, contain EEPROM that is not write-protected. The supplied version data identifies Linux 6.13 through affected 6.16.8/6.17 boundaries, but its exact range representation is ambiguous.
Exploitation context
The CVSS vector describes local access, low complexity, low privileges, and no user interaction, with high integrity and availability impact. The supplied record is not in KEV and provides no evidence of active exploitation. The documented destructive behavior is technically concrete, but real-world reach depends on driver use, hardware, permissions, and EEPROM protection.
Researcher notes
The central defect is integer underflow mapped through a four-bit hardware length field. Zero becomes the encoded maximum of 16 bytes rather than being rejected. Researchers should verify downstream backports and the exact affected-version boundaries because the supplied structured version list is unclear. No exploit code, public weaponization, or active campaign evidence is provided.
Mitigation direction
Update to a vendor-supported kernel containing the referenced RTL9300 I2C fix.
Check Linux distribution advisories for precise fixed versions and backport status.
Prevent zero-length SMBus Quick operations on affected systems until patched.
Enable EEPROM write protection where supported and operationally appropriate.
Restrict untrusted local access to interfaces capable of initiating I2C or SMBus transfers.
Validation and detection
Confirm whether the RTL9300 I2C controller driver is present and active.
Inventory kernel versions and compare vendor backports with both referenced stable commits.
Identify attached SFP modules or other components with writable, unprotected EEPROM.
Review whether local low-privileged processes can initiate SMBus Quick operations.
Validate fixes only with non-destructive tests in isolated hardware or vendor-approved procedures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-191: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-191 · source CWE mapping
Integer Underflow (Wrap or Wraparound)
Integer Underflow (Wrap or Wraparound) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.