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
Fix
Patch, vendor advisory and mitigation references on NVD 2
- https://git.kernel.org/stable/c/06418cb5a1a542a003fdb4ad8e76ea542d57cfba Patch
- https://git.kernel.org/stable/c/c91382328fc89f73144d5582f2d8f1dd3e41c8f7 Patch
Every line above is quoted from NVD, CISA, Microsoft, the vendor's own advisory or DISA; nothing is generated.
Change history 1
- First seenCVSS 5.5 · linuxNVD modified 2026-10-19 21:10
Affected (CPE criteria) 5
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*