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

On Tue, Jul 28, 2026, Jose Villaseñor Montfort wrote:
> Bail out of both callbacks when msc->input is NULL and leave the report
> to the generic HID paths, which is what those interfaces get today.
> Rejecting the bind in magicmouse_probe() instead would unbind interfaces
> that a healthy device legitimately exposes and drop their hidraw nodes.

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.

This is the right shape, and thanks for turning the v1 report around so
quickly. Both callbacks return 0, so reports on the input-less interfaces
keep flowing through the generic HID paths exactly as they do today, and
nothing about which interfaces bind changes.

Your ->event analysis holds up on a read of the code: hid_process_event()
calls ->event before the HID_CLAIMED_INPUT test, and with no usage_table
in this driver hid_match_usage() returns 1 for every usage, so the guard
in magicmouse_event() is doing real work rather than being defensive.

Tested on a Magic Trackpad 2 (05ac:0265) on 7.1.5, over both transports.
My tree carries the DOUBLE_REPORT_ID recursion fix [1], so the raw_event
guard went into __magicmouse_raw_event() -- the trivial rebase you
described; it sits above the size check, as in your patch.

Over USB all four HID interfaces bind to magicmouse and keep their nodes:

  0003:05AC:0265.0014  input48  hiddev102,hidraw7
  0003:05AC:0265.0015  input49  hiddev109,hidraw15
  0003:05AC:0265.0016  <none>   hiddev110,hidraw16
  0003:05AC:0265.0017  <none>   hiddev111,hidraw17

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. Pointer motion,
multi-finger gestures and clicks are unchanged, and the battery reads
74% "Charging" while cabled.

Over Bluetooth the trackpad reconnects and behaves the same, battery 74%
"Discharging" after unplugging, and a Magic Keyboard on the same host is
unaffected. No splats or call traces in dmesg on either transport.

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

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