On Jul 19 2025, Alan Stern wrote: > On Sat, Jul 19, 2025 at 10:36:01AM +0200, Benjamin Tissoires wrote: > > On Jul 17 2025, Alan Stern wrote: > > > Testing by the syzbot fuzzer showed that the HID core gets a > > > shift-out-of-bounds exception when it tries to convert a 32-bit > > > quantity to a 0-bit quantity. This is hardly an unexpected result, > > > but it means that we should not accept report fields that have a size > > > of zero bits. Similarly, there's no reason to accept report fields > > > with a count of zero; either type of item is completely meaningless > > > since no information can be conveyed in zero bits. > > > > > > Reject fields with a size or count of zero, and reject reports > > > containing such fields. > > > > > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > > Reported-by: syzbot+b63d677d63bcac06cf90@xxxxxxxxxxxxxxxxxxxxxxxxx > > > Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@xxxxxxxxxx/ > > > Tested-by: syzbot+b63d677d63bcac06cf90@xxxxxxxxxxxxxxxxxxxxxxxxx > > > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") > > > Cc: stable@xxxxxxxxxxxxxxx > > > Sigh... I applied this one too quickly before going on holidays. > > > > This breaks the hid testsuite: > > https://gitlab.freedesktop.org/bentiss/hid/-/jobs/80805946 > > > > (yes, I should have run it before applying). > > > > So basically, there are devices out there with a "broken" report size of > > 0, and this patch now entirely disables them. > > > > That Saitek gamepad has the following (see tools/testing/selftests/hid/tests/test_gamepad.py): > > 0x95, 0x01, # ..Report Count (1) 60 > > 0x75, 0x00, # ..Report Size (0) 62 > > 0x81, 0x03, # ..Input (Cnst,Var,Abs) 64 > > > > So we'd need to disable the field, but not invalidate the entire report. > > > > I'm glad I scheduled this one for the next cycle. > > > > I'll try to get something next week. > > So then would it be better to accept these report fields (perhaps with a > warning) and instead, harden the core HID code so that it doesn't choke > when it runs across one of them? > Yeah, that seems like the best plan forward. [sorry on reduced setup for the next 3 weeks, so I can't really debug the entire thing now.] Though, we should probably not annoy users unless we are trying to do something that won't be needed. I doubt that Saitek gamepad will ever call the faulty functions, so why putting an error in the logs when it's working fine? Cheers, Benjamin
