PT-2026-85623 · Linux · Linux
CVE-2026-80782
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: do not keep a stale msc->input if no input is claimed
magicmouse input mapping() caches the first hid input's input dev 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 hidinput connect()
fails -- for instance because input register device() returns an error --
it unwinds through hidinput disconnect(), which frees every input dev it
created, including the one cached in msc->input.
The failure does not abort the probe. hid connect() only skips the claim:
if ((connect mask & HID CONNECT HIDINPUT) && !hidinput connect(hdev,
connect mask & HID CONNECT HIDINPUT FORCE))
hdev->claimed |= HID CLAIMED INPUT;and the "device has no listeners" bailout below it does not fire for this
driver, which sets ->raw event; on the USB Magic Mouse 2 / Magic Trackpad
2 paths hidraw and hiddev are claimed as well. hid hw start() therefore
returns 0 and magicmouse probe() 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 ->raw event 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux