CVE-2025-39928
published 2025-10-01CVE-2025-39928: 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…
PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.12%
2.4th percentile
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
13 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.16.8-1 (forky) | linux 6.16.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= c366be720235301fdadf67e6f1ea6ff32669c074 < c91382328fc89f73144d5582f2d8f1dd3e41c8f7 | c91382328fc89f73144d5582f2d8f1dd3e41c8f7 |
| linux | linux | >= c366be720235301fdadf67e6f1ea6ff32669c074 < 06418cb5a1a542a003fdb4ad8e76ea542d57cfba | 06418cb5a1a542a003fdb4ad8e76ea542d57cfba |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.16.8-1 | 6.16.8-1 |
| linux | linux_kernel | >= 6.13 < 6.16.8 | 6.16.8 |
| msrc | cbl2_wireshark_3.4.14-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl_mariner_2.0_arm | — | — |
| msrc | cbl_mariner_2.0_x64 | — | — |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_msrc7.5HIGH
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: i2c: rtl9300: ensure data length is within supported range
vendor_redhat·2025-10-01·CVSS 5.5
CVE-2025-39928 [MEDIUM] kernel: i2c: rtl9300: ensure data length is within supported range
kernel: 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:
(
Debian
CVE-2025-39928: linux - In the Linux kernel, the following vulnerability has been resolved: i2c: rtl930...
vendor_debian·2025·CVSS 5.5
CVE-2025-39928 [MEDIUM] CVE-2025-39928: linux - In the Linux kernel, the following vulnerability has been resolved: i2c: rtl930...
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 vi
Microsoft
NULL pointer exception in the IEEE 802.11 dissector in Wireshark 3.4.0 to 3.4.9 and 3.2.0 to 3.2.17 allows denial of service via packet injection or crafted capture file
vendor_msrc·2021-11-09·CVSS 7.5
CVE-2021-39928 [HIGH] CWE-476 NULL pointer exception in the IEEE 802.11 dissector in Wireshark 3.4.0 to 3.4.9 and 3.2.0 to 3.2.17 allows denial of service via packet injection or crafted capture file
NULL pointer exception in the IEEE 802.11 dissector in Wireshark 3.4.0 to 3.4.9 and 3.2.0 to 3.2.17 allows denial of service via packet injection or crafted capture file
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
Mariner:
OSV
CVE-2025-39928: In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check f
osv·2025-10-01·CVSS 5.5
CVE-2025-39928 [MEDIUM] CVE-2025-39928: In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check f
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 vi
GHSA
GHSA-m43q-hvcx-4pxc: In the Linux kernel, the following vulnerability has been resolved:
i2c: rtl9300: ensure data length is within supported range
Add an explicit check
ghsa_unreviewed·2025-10-01
CVE-2025-39928 [MEDIUM] CWE-191 GHSA-m43q-hvcx-4pxc: In the Linux kernel, the following vulnerability has been resolved:
i2c: rtl9300: ensure data length is within supported range
Add an explicit check
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
No detection rules found.
No public exploits indexed.
2025-10-01
Published