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: <a7d352dd1d310bf07263106f2ce0f8ed@davidebeatrici.dev>
Date: Tue, 02 Dec 2025 20:41:24 +0100
From: Davide Beatrici <me@...idebeatrici.dev>
To: 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

Thank you very much for your feedback!

I can send you a new identical device for testing if you would like.

> 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)