ghsa-m43q-hvcx-4pxc
Vulnerability from github
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
{
"affected": [],
"aliases": [
"CVE-2025-39928"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T08:15:36Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: rtl9300: ensure data length is within supported range\n\nAdd an explicit check for the xfer length to \u0027rtl9300_i2c_config_xfer\u0027\nto ensure the data length isn\u0027t within the supported range. In\nparticular a data length of 0 is not supported by the hardware and\ncauses unintended or destructive behaviour.\n\nThis limitation becomes obvious when looking at the register\ndocumentation [1]. 4 bits are reserved for DATA_WIDTH and the value\nof these 4 bits is used as N + 1, allowing a data length range of\n1 \u003c= len \u003c= 16.\n\nAffected by this is the SMBus Quick Operation which works with a data\nlength of 0. Passing 0 as the length causes an underflow of the value\ndue to:\n\n(len - 1) \u0026 0xf\n\nand effectively specifying a transfer length of 16 via the registers.\nThis causes a 16-byte write operation instead of a Quick Write. For\nexample, on SFP modules without write-protected EEPROM this soft-bricks\nthem by overwriting some initial bytes.\n\nFor completeness, also add a quirk for the zero length.\n\n[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2",
"id": "GHSA-m43q-hvcx-4pxc",
"modified": "2025-10-01T09:30:25Z",
"published": "2025-10-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39928"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06418cb5a1a542a003fdb4ad8e76ea542d57cfba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c91382328fc89f73144d5582f2d8f1dd3e41c8f7"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.