linux-kernel - Re: [PATCH] HID: core: Reject report fields with a size or count of 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <voiysrjm3okjtaz7axqupr2jk5yyvxsqgagbwrsey4z24g6rf4@xb75ss3bwol5>
Date: Mon, 21 Jul 2025 15:05:58 +0200
From: Benjamin Tissoires <bentiss@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: syzbot <syzbot+b63d677d63bcac06cf90@...kaller.appspotmail.com>, 
	jikos@...nel.org, linux-input@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-usb@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] HID: core: Reject report fields with a size or count of 0

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@...land.harvard.edu>
> > > Reported-by: syzbot+b63d677d63bcac06cf90@...kaller.appspotmail.com
> > > Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
> > > Tested-by: syzbot+b63d677d63bcac06cf90@...kaller.appspotmail.com
> > > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> > > Cc: stable@...r.kernel.org
> 
> > 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