In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 2
- StatusReceived → PublishedNVD modified 2026-10-19 08:45
- First seenCVSS 7.8NVD modified 2026-10-19 09:17
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 8
- https://git.kernel.org/stable/c/0f6496b34cc2919420f303b2aabdd9f71e084b56
- https://git.kernel.org/stable/c/169ae5e65e5aaf213b6a578f6478a9fd2e523606
- https://git.kernel.org/stable/c/1d08877fc37e90945df38d255715bd1d6c052d46
- https://git.kernel.org/stable/c/6df05f630c84a109736642362e452089886f9974
- https://git.kernel.org/stable/c/ae0c79a8527044e54d81fd5a3b49ce6177633758
- https://git.kernel.org/stable/c/b30c021c6073559ea6851b522d8a17a524a27b4a
- https://git.kernel.org/stable/c/bf76d61e118b7044600a65775a3bf8adc2c6823d
- https://git.kernel.org/stable/c/cb55c5da9828f77db2a2701316949d4de1e9b773