CVE-2026-80782: HID: magicmouse: do not keep a stale msc->input if no input is claimed
In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: do not keep a stale msc->input if no input is claimed
magicmouseinputmapping() caches the first hidinput's inputdev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered.
That does not hold on the hid-input error path. If hidinputconnect() fails -- for instance because inputregisterdevice() returns an error -- it unwinds through hidinputdisconnect(), which frees every inputdev it created, including the one cached in msc->input.
The failure does not abort the probe. hidconnect() only skips the claim:
if ((connectmask & HIDCONNECTHIDINPUT) && !hidinputconnect(hdev, connectmask & HIDCONNECTHIDINPUTFORCE)) hdev->claimed |= HIDCLAIMEDINPUT;
and the "device has no listeners" bailout below it does not fire for this driver, which sets ->rawevent; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hidhwstart() therefore returns 0 and magicmouseprobe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the "input not registered" check in probe and the NULL checks in ->rawevent and ->event, so the next input report dereferences freed memory.
Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.
Affected Software
Event History
Frequently Asked Questions
Which hardware paths are implicated?
The issue is described on the USB Magic Mouse 2 and Magic Trackpad 2 paths. On those paths, hidraw and hiddev can still be claimed even when HID input setup fails.
What condition is needed to trigger the stale pointer?
HID input connection must fail after the driver has cached an input device pointer, such as when input_register_device() returns an error. Cleanup then frees the cached input device while the driver retains the non-NULL pointer.
Does failure to register the input device stop the driver from probing?
No. The failed HID input connection causes the input claim to be skipped, but hid_hw_start() can still return success because other interfaces are claimed and the driver provides raw_event support.