Hi Paul,
thanks for your comments.
----Do you have reproducer to forth an invalid length?
Yes. The issue is reproducible with a concrete system call sequence.
I am running on top of a fuzzer called PrIntFuzz, which is built on syzkaller. PrIntFuzz adds a custom syscall syz_prepare_data() that is used to simulate device input. In other words, the device side traffic is not coming from a real hardware device, but is deliberately constructed by the fuzzer through syz_prepare_data().
The exact reproducer is provided in the attached syzkaller program (system call sequence) generated by PrIntFuzz, which consistently triggers the invalid length and the crash on my setup.
(The attached program is exactly the sequence I am running to reproduce the problem.)
----Should an error be logged, or is it a common scenario, that such traffic exists?
In normal deployments, I don’t expect such traffic from a well-behaved I2C device. In my case, the malformed length only appears because PrIntFuzz is intentionally crafting invalid inputs and feeding them to the driver via syz_prepare_data(). So this is not a “common” or expected scenario in real-world use, but it is a realistic attacker/fuzzer scenario, since the length field can be controlled by an external peer/device.
Given that, I think the driver should treat an invalid length as an error and fail the request instead of trusting it and risking memory corruption.
Regarding logging, I’m fully open to your preference. From my point of view, logging this as an error seems reasonable, because it indicates malformed or buggy input from the device side. However, if you expect this condition might occur more frequently in practice and would prefer to reduce noise, I can switch it to dev_dbg() or even drop the log entirely.
Please let me know which logging level you would prefer, and I will update the patch accordingly.
Best regards, Guangshuo Li