Cloudanix VulnDB

CVE-2026-80782

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel handles certain mouse and trackpad devices can leave behind a reference to already-freed memory, which could cause crashes or be misused by an attacker with physical device access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free caused by a stale pointer to a freed input_dev structure that remains non-NULL after hidinput_connect fails during probe of the magicmouse HID driver, allowing subsequent raw_event and event handlers to dereference invalid memory.

Why it matters to the business

Kernel instability or potential local privilege escalation on Linux systems using Magic Mouse or Magic Trackpad devices; low public exploit activity reduces immediate operational risk but still requires prompt patching to avoid crashes during device initialization.

How an attack unfolds

An attacker with the ability to trigger a failed hidinput_connect (for example via malformed report descriptors or resource exhaustion) leaves msc->input pointing to freed memory; subsequent input reports then cause the driver to dereference the dangling pointer, leading to a use-after-free condition.

How to fix it

Apply the upstream kernel patch that clears msc->input when HID core does not claim an input device; rebuild and deploy the fixed kernel image on all affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the magicmouse driver source for the added clearing of msc->input on hidinput_connect failure; test probe paths with forced hidinput_connect errors and verify no use-after-free occurs under memory debugging tools such as KASAN.

Typical attack path

  1. Attach or emulate a Magic Mouse 2 / Trackpad 2 device during kernel module load or probe
  2. Force hidinput_connect to fail so that the cached input_dev is freed without clearing the pointer
  3. Send subsequent HID input reports that reach magicmouse_raw_event or magicmouse_event
  4. Trigger dereference of the freed memory to achieve crash or memory corruption

How to detect it

Review kernel logs for magicmouse-related oops or use-after-free reports during device probe; inspect dmesg and journalctl output for hid_connect failures followed by later input report handling on the same device.

What your security team should do

  • Prioritize kernel updates on any Linux endpoints that interact with Apple Magic Mouse or Trackpad hardware
  • Monitor upstream stable kernel releases for backported fixes and schedule rollout within standard change windows
  • Enable kernel hardening features such as KASAN in test environments to validate the fix

The record

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.

Affected packages

Ecosystem Package Introduced Fixed