w1: ds28e17: possible out of bounds write from a device length byte

w1: ds28e17: possible out of bounds write from a device length byte

[Maoyi Xie]

Hi all,

I think w1_f19_i2c_master_transfer() in drivers/w1/slaves/w1_ds28e17.c can
write past the SMBus buffer when an I2C device behind the DS28E17 bridge
reports a large length. I would appreciate it if you could take a look.

On an I2C_M_RECV_LEN read the driver takes the length from the device.

	if (msgs[i].flags & I2C_M_RECV_LEN) {
		result = w1_f19_i2c_read(sl, msgs[i].addr,
			&(msgs[i].buf[1]), msgs[i].buf[0]);

buf[0] is the length byte a previous read filled in from the device, so it
can be anything from 0 to 255. w1_f19_i2c_read() only rejects a zero count
and then writes that many bytes into buf[1].

The buffer the SMBus core hands in is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes,
with msg.len set to 1. A device that reports a length above 32 makes the
read run past the 34 byte buffer, up to about 222 bytes out of bounds.

The SMBus emulation does check buf[0] against I2C_SMBUS_BLOCK_MAX, but that
runs after the transfer returns, so it cannot stop the write that already
happened. A compliant bit banging adapter rejects the over long length
before copying, in i2c-algo-bit.

The attacker here is a malicious or faulty I2C device sitting behind a
DS28E17 1-wire to I2C bridge. It controls the length byte it returns.

I reproduced it under KASAN on 7.1-rc7. With a length of 32 the write stays
inside the buffer. With a length of 255 KASAN reports a slab out of bounds
write past the 34 byte allocation.

The fix I tried rejects a length above I2C_SMBUS_BLOCK_MAX at the two
I2C_M_RECV_LEN sites, before the second read.

Does this look like a real bug to you? If it does I am happy to send a
proper patch with a Fixes tag pointing at ebc4768ac497 ("add w1_ds28e17
driver for the DS28E17 Onewire to I2C master bridge").

Thanks,
Maoyi
https://maoyixie.com/

Re: w1: ds28e17: possible out of bounds write from a device length byte

[Krzysztof Kozlowski]

On 18/06/2026 11:58, Maoyi Xie wrote:
> Hi all,
> 
> I think w1_f19_i2c_master_transfer() in drivers/w1/slaves/w1_ds28e17.c can
> write past the SMBus buffer when an I2C device behind the DS28E17 bridge
> reports a large length. I would appreciate it if you could take a look.
> 
> On an I2C_M_RECV_LEN read the driver takes the length from the device.
> 
> 	if (msgs[i].flags & I2C_M_RECV_LEN) {
> 		result = w1_f19_i2c_read(sl, msgs[i].addr,
> 			&(msgs[i].buf[1]), msgs[i].buf[0]);
> 
> buf[0] is the length byte a previous read filled in from the device, so it
> can be anything from 0 to 255. w1_f19_i2c_read() only rejects a zero count
> and then writes that many bytes into buf[1].

That's exactly the bug AI tends to find... Easy to spot pattern and then
figuring out the logic leading to it. Maybe it is real, maybe not, but
the AI feels like too big threat of wasting my time (and you did not
even disclose it).

Reading based on length supplied by device is of course risky, but isn't
the rest of the master_xfer implementations doing the same? IOW, what is
different here? Or they do not do it, so you have the answer to your
question?

> 
> The buffer the SMBus core hands in is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes,
> with msg.len set to 1. A device that reports a length above 32 makes the
> read run past the 34 byte buffer, up to about 222 bytes out of bounds.
> 
> The SMBus emulation does check buf[0] against I2C_SMBUS_BLOCK_MAX, but that
> runs after the transfer returns, so it cannot stop the write that already
> happened. A compliant bit banging adapter rejects the over long length
> before copying, in i2c-algo-bit.
> 
> The attacker here is a malicious or faulty I2C device sitting behind a

Malicious DS28E17? Feels like AI convinced you that it is a thing...

> DS28E17 1-wire to I2C bridge. It controls the length byte it returns.
> 
> I reproduced it under KASAN on 7.1-rc7. With a length of 32 the write stays

How did you reproduce it? Do you have ds28e17?



> inside the buffer. With a length of 255 KASAN reports a slab out of bounds
> write past the 34 byte allocation.
> 
> The fix I tried rejects a length above I2C_SMBUS_BLOCK_MAX at the two
> I2C_M_RECV_LEN sites, before the second read.
> 
> Does this look like a real bug to you? If it does I am happy to send a

Did not investigate enough to judge. I am sorry but my expectation is
not to investigate AI-based reports. Expectation is rather to get a
human created and human validated patch, regardless whether human or AI
produced the report.

Best regards,
Krzysztof

Re: w1: ds28e17: possible out of bounds write from a device length byte

[Maoyi Xie]

Hi Krzysztof,

> That's exactly the bug AI tends to find... Easy to spot pattern and then
> figuring out the logic leading to it. Maybe it is real, maybe not, but
> the AI feels like too big threat of wasting my time (and you did not
> even disclose it).

I used AI assistance on this report and did not say so. Sorry for that.

> Reading based on length supplied by device is of course risky, but isn't
> the rest of the master_xfer implementations doing the same? IOW, what is
> different here? Or they do not do it, so you have the answer to your
> question?

No. They bound it. i2c-algo-bit returns -EPROTO from readbytes() when the
device length is above I2C_SMBUS_BLOCK_MAX, before it copies. Several other
drivers do the same. w1_f19_i2c_read() only rejects a zero count, then
writes buf[0] bytes into &buf[1] with no upper bound. So ds28e17 is the
outlier.

> Malicious DS28E17? Feels like AI convinced you that it is a thing...

The length comes from the device behind the bridge, not the DS28E17 itself.

> How did you reproduce it? Do you have ds28e17?

No, I do not have the hardware. The KASAN result came from a small harness
that drives w1_f19_i2c_master_transfer() with a 255 length, not from a real
device. Sorry, I should have said that plainly.

> Did not investigate enough to judge. I am sorry but my expectation is not
> to investigate AI-based reports. Expectation is rather to get a human
> created and human validated patch, regardless whether human or AI produced
> the report.

Understood. Let me send a proper [PATCH] so you can judge the code, not my
report. It bounds the length at the two I2C_M_RECV_LEN sites and returns
-EPROTO, the same check i2c-algo-bit uses. It builds clean.

Thanks,
Maoyi