Re: [PATCH v2] HID: magicmouse: avoid NULL pointer deref when there is no input device

On Sun, Aug 02, 2026, Alec Hall wrote:
> Apologies for the near-week delay in getting back to you -- I was away on
> an anniversary trip and without physical access to the test machine for
> part of it, which this needed. Sorry to have left you waiting.

No apology needed -- you got to it faster than I did. Thank you for the
three reviews, and particularly for the fault injection on the stale
pointer one: reproducing that state at all took more effort than the
patch did, and being explicit about what it does not show (a real
input_register_device() failure, and no KASAN) is exactly the caveat I
would have wanted stated.

> Interfaces 2 and 3 bind with msc->input == NULL, as they always have, and
> there are no probe failures in dmesg -- the two "magicmouse input not
> registered" lines per plug that v1 produced are gone.

Good, that is the behaviour the v1 broke and the whole point of the
respin. Thanks for checking the Magic Keyboard on the same host too.

Jiri, this one now carries

  Reviewed-by: Alec Hall <[email protected]>
  Tested-by: Alec Hall <[email protected]>

from the message I am replying to. I mention it because you have already
applied its sibling, "HID: magicmouse: do not keep a stale msc->input if
no input is claimed", and the two are a pair: that one deliberately sets
msc->input to NULL when the core claimed no input, on the basis that the
NULL checks in ->raw_event and ->event -- which this patch adds -- make
NULL the safe state. Applied on its own it turns a dangling pointer into
a NULL one, which is an improvement but not the whole fix.

That is also the answer to the Sashiko review of the stale patch [1],
which asked whether clearing msc->input could leave a NULL dereference
reachable through the early return on the USB Magic Mouse 2 / Magic
Trackpad 2 path. It can, but that is not something the stale patch
introduces: as Alec's dmesg above shows, the input-less vendor interfaces
of a healthy trackpad have always reached ->raw_event and ->event with
msc->input == NULL. Closing that is what this patch is for.

> a device with a 16-bit or bit-packed capacity would read garbage
> silently. A guard that falls back rather than mis-reading might be
> worth it.

Agreed, and thanks for spelling out that it is not a regression. The
byte-aligned assumption is a real limit of what went in.

Worth flagging here, because it is exactly that and has had no replies
since it was posted: Mason Camara sent a series on Jul 12 that records
the field offset and size and reads the value with hid_field_extract(),
so a bit-packed or non-byte-aligned capacity is handled, and it comes
with a UHID selftest:

  https://lore.kernel.org/linux-input/[email protected]/

To be straight about where I stand on it: I only found it after sending
my v2, I have read it but have not built or tested it, and I have not
written in that thread yet. On a read it is the more general of the two
fixes. I will follow up with Mason there rather than prolong this thread.

[1] https://lore.kernel.org/linux-input/[email protected]/

Thanks,
Jose