linux-kernel - Re: [PATCH] HID: validate report length and constants

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: <91117308-7eb5-4258-ac87-1afb2d46d2b5@cosmicgizmosystems.com>
Date: Tue, 2 Dec 2025 13:40:49 -0800
From: Terry Junge <linuxhid@...micgizmosystems.com>
To: Davide Beatrici <me@...idebeatrici.dev>,
 Benjamin Tissoires <bentiss@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
 jikos@...nel.org, benjamin.tissoires@...hat.com
Subject: Re: [PATCH] HID: validate report length and constants



On 12/2/25 11:41 AM, Davide Beatrici wrote:
> Thank you very much for your feedback!
> 
> I can send you a new identical device for testing if you would like.
> 

Can you supply the Device, Configuration, and Report Descriptors?

Thanks,
Terry

>> Can you show us what packets are emitted?
>>
>> If it's a firmware bug, we better have a specific driver for it could
>> be a HID-BPF program that just filters out the unwanted reports.
>>
>> Also, how does Windows behave with this mouse? Does it need a special
>> driver?
> 
> Sorry, I should've mentioned the malformed packet also shows up on Windows,
> but is seemingly ignored because there appear to be no side effects whatsoever.
> 
> No special driver needed, it's detected as a standard HID mouse.
> 
> WireShark capture:
> https://dl.houseof.software/misc/atk_x1_se_malformed_packet.pcapng
> 
> Packet screenshot:
> https://dl.houseof.software/misc/atk_x1_se_malformed_packet.png
> 
>> Looks like there is something wrong either in the report descriptor of
>> this mouse, either in the emitted reports.
> 
> Definitely. I have already informed the manufacturer, who confirmed the mouse
> has only been tested on Windows.
> 
> My inquiry was forwarded to their R&D team, hopefully a firmware update will
> be released soon.
> 
>> Yep, this is on purpose because Miscrosoft's own driver works that way
>> and many HID devices do not bother to mark the non constant bits as
>> data. So if you enforce the spec here, you'll break a numerous of
>> devices unfortunatelly.
> 
>> Ouch. If I read you correctly, you are rejecting the entire report if a
>> constant field is not 0. It is common for constant fields to be just
>> garbage (whatever is in the memory, because writing firmware is hard),
>> so even if we were to accept this patch, this would break even more
>> devices :(
> 
>> I am pretty sure the HID selftests will fail with this patch applied,
>> because there are probably a couple of devices there with the "non
>> constant" behaviour.
> 
> Oh, in that case let's just drop that part from the patch, since it's
> actually not altering the behavior with this specific device.
> 
> The malformed packet is detected and rejected by two checks:
> 
> Malformed report: raw_len=1 payload_len=1 expected=8 (ID 0)
> Malformed report: const slice OOB (bit_off 8, len 8)
>