Hi Paul,
Thanks for your reply.
To run the reproducer, you'll first need to download the PrIntFuzz project from https://github.com/vul337/PrIntFuzz and set up the environment. Once that is done, you should be able to run the attached syzkaller program to reproduce the issue.
Kind regards, Guangshuo
Paul Menzel pmenzel@molgen.mpg.de 于2025年12月2日周二 19:53写道：
Dear Guangshuo,
Thank you for your quick and insightful reply. (No need to resend this often.)
Am 02.12.25 um 12:34 schrieb Guangshuo Li:
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.)
Thank you for attaching it. Excuse my ignorance, but how do I run it?
----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.
Then I’d suggest to add an error message with error level so people notice and can take a look.
Kind regards,
Paul