HID: magicmouse: do not keep a stale msc->input if no input is claimed
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.9, 5.10.269, 5.15.218, 6.1.185, 6.6.154, and 4 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in c3597923932bb90d4fc2186aef552f6677175e4a; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in e0c224c93d10ee38854fdf24c815108aedd3dcb3; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 403cc9bd6ccb9fbe68d501c3236e5a6dd5504e14; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 3d7a7bac4c75f25b2513505a0ac5ba909588ed2b; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 9bdf8c7bfd79f1090e61d28f969b32880fd77bb3; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 15b60ade825c8ce9ec560048a4ae3747e4572be3; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 0bf253e9ac994cb5329bc87b00bb4eeca9136791; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 2ef16934e069d5f771e989d6ee5c3ece5042f3cd; From f1a9a149abc86903e81dd1b2e720f3f89874384b · fixed in 0af3b89705688af01aa06025b84fa7a1e06ba6cc; From 3.8.7 · fixed in 3.9
- Linux Linux
3.9
- KernelLinux
From 3.9.0 · fixed in 5.10.269; From 5.11.0 · fixed in 5.15.218; From 5.16.0 · fixed in 6.1.185; From 6.2.0 · fixed in 6.6.154; From 6.7.0 · fixed in 6.12.106; From 6.13.0 · fixed in 6.18.47; From 6.19.0 · fixed in 7.1.11; From 7.2.0 · fixed in 7.2.1
References 9
git.kernel.org
- stable/c/c3597923932bb90d4fc2186aef552f6677175e4a
- stable/c/e0c224c93d10ee38854fdf24c815108aedd3dcb3
- stable/c/403cc9bd6ccb9fbe68d501c3236e5a6dd5504e14
- stable/c/3d7a7bac4c75f25b2513505a0ac5ba909588ed2b
- stable/c/9bdf8c7bfd79f1090e61d28f969b32880fd77bb3
- stable/c/15b60ade825c8ce9ec560048a4ae3747e4572be3
- stable/c/0bf253e9ac994cb5329bc87b00bb4eeca9136791
- stable/c/2ef16934e069d5f771e989d6ee5c3ece5042f3cd
- stable/c/0af3b89705688af01aa06025b84fa7a1e06ba6cc