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? Alan Stern
