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