The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Davide Beatrici <me@davidebeatrici.dev>
To: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	jikos@kernel.org, benjamin.tissoires@redhat.com
Subject: Re: [PATCH] HID: validate report length and constants
Date: Tue, 02 Dec 2025 20:41:24 +0100	[thread overview]
Message-ID: <a7d352dd1d310bf07263106f2ce0f8ed@davidebeatrici.dev> (raw)
In-Reply-To: <xyh6scqrfzft3hhmqowyverzezb2xsmsexegk3sydyfbiknba4@6sy3qbtsinrr>

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)

  reply	other threads:[~2025-12-02 19:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  5:36 [PATCH] HID: validate report length and constants Davide Beatrici
2025-12-02  8:22 ` Benjamin Tissoires
2025-12-02 19:41   ` Davide Beatrici [this message]
2025-12-02 21:40     ` Terry Junge
2025-12-02 21:54       ` Davide Beatrici
2025-12-04  9:53         ` Benjamin Tissoires
2025-12-04 19:48           ` Davide Beatrici
2025-12-04 23:43             ` Davide Beatrici
2025-12-08  8:54               ` Benjamin Tissoires
2025-12-12  6:22                 ` Davide Beatrici

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7d352dd1d310bf07263106f2ce0f8ed@davidebeatrici.dev \
    --to=me@davidebeatrici.dev \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox