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 <[email protected]> 于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
