CVE-2026-80782
CVE CVE-2026-80782EUVD EUVD-2026-71425Published 2026-09-04T15:12:53.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux 3.9; f1a9a149abc86903e81dd1b2e720f3f89874384b <3d7a7bac4c75f25b2513505a0ac5ba909588ed2b; f1a9a149abc86903e81dd1b2e720f3f89874384b <0af3b89705688af01aa06025b84fa7a1e06ba6cc; patch: 5.15.218; f1a9a149abc86903e81dd1b2e720f3f89874384b <0bf253e9ac994cb5329bc87b00bb4eeca9136791; f1a9a149abc86903e81dd1b2e720f3f89874384b <9bdf8c7bfd79f1090e61d28f969b32880fd77bb3; patch: 6.1.185; f1a9a149abc86903e81dd1b2e720f3f89874384b <c3597923932bb90d4fc2186aef552f6677175e4a; f1a9a149abc86903e81dd1b2e720f3f89874384b <e0c224c93d10ee38854fdf24c815108aedd3dcb3; 0e55072e7c63a6569cab1447e9025d160abd9dd9; patch: 0; patch: 6.18.47; f1a9a149abc86903e81dd1b2e720f3f89874384b <2ef16934e069d5f771e989d6ee5c3ece5042f3cd; 3.8.7 <3.9; patch: 7.2.1; patch: 5.10.269; patch: 6.12.106; patch: 7.3-rc1; f1a9a149abc86903e81dd1b2e720f3f89874384b <403cc9bd6ccb9fbe68d501c3236e5a6dd5504e14; patch: 6.6.154; f1a9a149abc86903e81dd1b2e720f3f89874384b <15b60ade825c8ce9ec560048a4ae3747e4572be3; patch: 7.1.11
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.