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

CVE-2026-80782

Affected Products

Linux