Re: [PATCH] HID: magicmouse: do not keep a stale msc->input if no input is claimed

On Tue, Jul 28, 2026, Jose Villaseñor Montfort wrote:
> Clear msc->input when the HID core did not claim an input device, so the
> existing NULL checks cover this case as well.

Reviewed the path and agree with the analysis. Trusting hdev->claimed
rather than the cached pointer is the right signal: it is set by the core
from the outcome of hidinput_connect(), whereas msc->input is set from
->input_mapping while the descriptor is parsed, long before anyone knows
whether the registration will succeed.

One data point in support of the "hid_hw_start() still returns 0" step,
from instrumenting the earlier v1 report on a USB Magic Trackpad 2: the
input-less vendor interfaces reach magicmouse_probe() with
hdev->claimed == 0x6 (HIDRAW|HIDDEV, no HID_CLAIMED_INPUT) and probe
carries on normally. That is the same "core claimed no input, probe
continues" state your patch keys off, just arrived at without an error.

Note the driver already clears msc->input in magicmouse_input_configured()
when its own setup fails, so this closes the remaining door: hid-input
unwinding for a reason the driver never sees.

Tested on a Magic Trackpad 2 [Lightning] (05ac:0265) on 7.1.5, with your sibling
guards patch [1] also applied. Since input_register_device() does not fail
on real hardware, I reproduced the state with a test-only fault injection:
a module parameter making magicmouse_input_configured() return -EINVAL
*without* clearing msc->input. hid-input then unwinds and frees the
input_dev that ->input_mapping had already cached, and hid_hw_start()
returns 0 -- the same dangling msc->input your patch describes, reached
from a failure the driver did not cause itself.

Without your patch (fix disabled at runtime, injection armed), plugging in
over USB:

  magicmouse 0003:05AC:0265.0022: hiddev109,hidraw16: USB HID v1.10 Mouse
      [Apple Inc. Magic Trackpad 2] on usb-0000:00:14.0-8/input1

The boot-protocol interface binds. No "magicmouse input not registered",
because the freed-but-non-NULL pointer passes that check exactly as you
said it would, and the driver goes on to arm the device.

With your patch, the same plug:

  magicmouse 0003:05AC:0265.0014: magicmouse input not registered
  magicmouse 0003:05AC:0265.0014: probe with driver magicmouse failed with error -12

The pointer is cleared, the existing check fires, and that interface
refuses to bind instead of running with freed memory. The interfaces that
take the early return bind inert with hiddev/hidraw only, and over
Bluetooth the device fails probe the same way. No oops or corruption in
either configuration, and disarming the injection restores normal
operation on both transports (touch, gestures, battery 76% Discharging
over BT, 74% Charging over USB).

Caveat on the above: this reproduces the dangling-pointer state, not an
actual input_register_device() failure, and the kernel here has no KASAN,
so I deliberately did not drive input reports through the unpatched case
-- the evidence is that the check passes when it should not, at probe
time.

On your open questions: f1a9a149abc8 reads right to me for the Fixes: tag,
since that is where probe() began treating a non-NULL msc->input as proof
of registration, and the commit message is clear that the dangling pointer
predates it. I would keep the stable Cc -- it is a use-after-free, and
"hard to trigger" is about allocation failure rather than anything a
device can or cannot do -- but that is a maintainer call.

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

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