CVE-2026-80931: w1: ds28e17: reject an oversize length on an I2C block read
In the Linux kernel, the following vulnerability has been resolved:
w1: ds28e17: reject an oversize length on an I2C block read
w1f19i2cmastertransfer() is the masterxfer for the DS28E17 1-Wire to I2C bridge. On an I2CMRECVLEN 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 w1f19i2cread().
buf[0] is controlled by the device and can be 0 to 255. w1f19i2cread() only rejects a zero count. The caller buffer is I2CSMBUSBLOCKMAX + 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 I2CSMBUSBLOCKMAX. That check runs after masterxfer 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 I2CSMBUSBLOCKMAX at both RECVLEN sites, the same way i2c-algo-bit does.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel w1: ds28e17to a version that resolves this vulnerability.Patch resolved
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the DS28E17 1-Wire-to-I2C bridge driver are exposed when it performs an I2C_M_RECV_LEN read from a downstream I2C slave. The issue depends on a device-controlled length byte supplied by that downstream slave.
What does an attacker or malicious device need to do to trigger the flaw?
The downstream I2C slave must return a block length greater than I2C_SMBUS_BLOCK_MAX, which is 32 bytes. Before the fix, the driver uses that value to read into a 34-byte caller buffer, allowing an out-of-bounds write of up to about 222 bytes.
Does the SMBus core length validation prevent exploitation?
No. The SMBus core checks the returned length only after the driver's master transfer function has completed, so the out-of-bounds write has already occurred.
What behavior changes with the fix?
The driver rejects receive-length values above I2C_SMBUS_BLOCK_MAX at both I2C_M_RECV_LEN handling sites, matching the behavior of i2c-algo-bit. Oversize lengths are rejected rather than copied into the fixed-size buffer.