Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)

[Benjamin Tissoires <bentiss@kernel.org>]

On Apr 14 2026, Thorsten Leemhuis wrote:
> On 4/8/26 17:41, Benjamin Tissoires wrote:
> > Definitely not a big fan of that new quirk. The issue is that current
> > hid-core fix is too restrictive because it doesn't have enough
> > information, like the actual allocated buffer size.
> > 
> > On Apr 08 2026, Zhouwang Huang wrote:
> >> Commit 9e2a17d2e808 ("HID: gpd: fix report descriptor on GPD Win
> >> handheld (2f24:0137)") used report_fixup to shrink Report Count from
> >> 63 to 11 so that short reports from firmware <= 1.09 would not be
> >> rejected by hid_report_raw_event().
> >>
> >> However, firmware 1.10 fixed the report length and now sends the full
> >> 63 bytes.  Because report_fixup already shrank the descriptor,
> >> usbhid allocates a 12-byte URB buffer — far too small for the 64-byte
> >> transfer — causing continuous -EOVERFLOW on every interrupt-in URB.
> >> The HID report descriptor and bcdDevice are identical across firmware
> >> versions, so report_fixup cannot conditionally apply.
> > 
> > OK, so if a firmware already fixed the bug, I'll drop 9e2a17d2e808 from
> > for-next and not include it in the final 7.0 PR I'll need to send.
> 
> Well, that meanwhile dropped commit 9e2a17d2e808 ("HID: gpd: fix report
> descriptor on GPD Win handheld (2f24:0137)") was supposed to fix a
> regression honjow (now CCed) reported on 2026-03-23:
> https://bugzilla.kernel.org/show_bug.cgi?id=221271
> https://lore.kernel.org/all/20260324013847.68024-1-honjow311@gmail.com/
> 
> So it is still unfixed as of now, I assume?

correct. But the HW is faulty and a new firmware version works, so it's
not like there is no options. But...

> 
> Side note: was honjow even notified about dropping the commit?

Not sure we replied to the original thread. That's an omission from us,
but OTH, the "fix" was only in linux-next, never in a realease kernel,
so it was just a delay introduced.

> 
> > We can tell people to upgrade to the latest firmware
> 
> Well, that should not be required by users when it comes to regressions
> -- unless maybe no other way to fix a severe issue can be found. Is that
> the case here?

Sigh. The fix that was introduced in the previous release cycle was a
"security" one. Which explained it had a fast path in being merged into
the kernel and into stable. I hate those but there was something
fundamentally wrong in the hid core code. We already got numerous
reports that the fix is not breaking other devices but is way too
verbose, so a proper fix is on its way, as soon as I managed to properly
test it on my machine.

> 
> > while I work on a proper fix.
> 
> How far is a proper fix away? And will that be GPD Win specific, or fix

Should be out today or tomorrow, depending if my machine still randomly
freeze because of the latest 7.0-rc bugs

GPD specific -> no, it's basically restoring the old behaviour where we
authorize shorter reports, but only if the provided buffer is big
enough. This is is the case when we are dealing with an actual call from
a transport layer like USB or I2C, but not from uhid.

> issues with other issues, too. Because Anj D (now CCed) recently
> reported a flooded dmesg caused by 0a3fe972a7cb ("HID: core: Mitigate
> potential OOB by removing bogus memset()") with a APC UPS (USB VID/PID
> 051D:0002):
> https://lore.kernel.org/all/MW5PR84MB135613E7947113897DD9FDA4C7272@MW5PR84MB1356.NAMPRD84.PROD.OUTLOOK.COM/
> 
> That's with 6.19.12, as the commit was recently backported to 6.18.y and
> 6.19.y.

Yes, again, please redirect your wrath to the persons who decided that
this kind of bugs (that we admitedly have to fix) are security in some
cases :) 

But yeah, security bugs are an annoyance for anybody, and we are far
from seeing the end of it.

Cheers,
Benjamin