CVE-2026-31522

What it actually does

This is a local denial-of-service flaw in the Linux kernel HID Magic Mouse driver. The driver’s report descriptor fixup path allocates memory with kmemdup() and returns it without a corresponding free, causing a kernel memory leak each time the vulnerable path is triggered. Repeated triggering can exhaust kernel memory and lead to severe memory pressure, OOM-killer activity, service disruption, or a system crash. The issue does not provide confidentiality or integrity impact and does not directly grant code execution or privilege escalation.

Why it matters to the business

Systems that load the vulnerable Magic Mouse HID driver can be made unstable or unavailable by a local attacker or by repeated interaction with a crafted or malfunctioning compatible HID device. The practical impact is outage risk for Linux endpoints, kiosks, workstations, or specialized systems where local users or attached Bluetooth/USB HID devices are not tightly controlled. The low EPSS score, lack of known exploit maturity, and absence from CISA KEV indicate limited observed exploitation, but exposed shared workstations and systems accepting untrusted peripherals should still be prioritized because the impact is availability loss.

How an attack unfolds

An attacker needs local ability to interact with the target’s HID subsystem, such as the ability to attach or emulate a compatible USB/Bluetooth HID device, pair a Bluetooth device, or otherwise cause the vulnerable Magic Mouse driver to parse report descriptors. The attacker repeatedly triggers the report_fixup path handled by the Magic Mouse driver. Each trigger leaks kernel memory because the allocated replacement descriptor is not freed by the driver or caller. Over time, leaked memory accumulates, reducing available kernel memory until the system experiences memory pressure, invokes the OOM killer, degrades service performance, or crashes. Because the flaw is local and availability-only, exploitation is most relevant where untrusted users or peripherals can interact with Linux systems.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for the HID Magic Mouse report descriptor memory leak. No exact fixed package versions were provided, so track the advisory for the specific Linux distribution, kernel flavor, and support channel in use. Where immediate patching is not possible, reduce exposure by preventing untrusted USB/Bluetooth HID devices, disabling Bluetooth pairing on systems that do not require it, blocking physical access to peripheral ports, or blacklisting/unloading the Magic Mouse HID driver where Magic Mouse support is unnecessary. Driver-level mitigation may include disabling the hid_magicmouse/hid-magicmouse module through modprobe configuration, subject to distribution naming and operational requirements.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor patch for the Magic Mouse HID report_fixup memory leak. Review distribution changelogs or kernel source to ensure the vulnerable magicmouse_report_fixup() behavior no longer returns an unowned kmemdup()-allocated buffer. On systems where the feature is not needed, validate that the Magic Mouse HID driver is not loaded and cannot be autoloaded. For exposure checks, inventory Linux hosts with the Magic Mouse HID driver available or loaded, Bluetooth enabled, or permissive USB peripheral access. In a controlled test environment only, use kernel memory leak diagnostics such as kmemleak or memory pressure monitoring while repeatedly connecting a compatible HID device to confirm memory is no longer leaked.

Typical attack path

1. Gain local access to the Linux system or physical/proximity access sufficient to attach or pair a HID device.
2. Ensure the vulnerable Magic Mouse HID driver is loaded or trigger device matching that causes it to load.
3. Present a crafted, emulated, or repeatedly reconnected compatible HID report descriptor that exercises the vulnerable report fixup routine.
4. Repeat the trigger to accumulate unreleased kernel allocations.
5. Cause system-wide memory pressure, OOM-killer events, degraded services, or a kernel/system crash.

How to detect it

There is no reliable single artifact proving exploitation because the vulnerability manifests as a kernel memory leak and denial of service rather than file creation or command execution. To assess possible prior exploitation, review kernel logs, system journals, Bluetooth logs, USB device history, and endpoint telemetry for repeated Magic Mouse or HID device attachment events followed by increasing memory pressure, OOM-killer activity, service terminations, or crashes. Useful sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, bluetoothd logs, audit logs for module loading, EDR device-control telemetry, and crash dumps. Look for temporal correlation between hid_magicmouse or Magic Mouse activity and OOM events. Also review whether the driver was loaded on systems where Magic Mouse use is unexpected, as that may indicate peripheral probing or emulation. Absence of these artifacts does not rule out exploitation, especially if logs rotated after a crash.

• magicmouse_report_fixup
• hid_magicmouse
• hid-magicmouse
• Magic Mouse
• Apple Magic Mouse
• Apple Magic Trackpad
• invoked oom-killer
• Out of memory
• Memory allocation failure
• oom-kill
• bluetoothd
• USB HID
• HID report descriptor
• /sys/module/hid_magicmouse
• /sys/bus/hid/drivers/magicmouse
• modprobe hid_magicmouse
• modprobe hid-magicmouse

What your security team should do

• Prioritize patching Linux workstations, shared systems, kiosks, lab machines, and any systems where untrusted users can attach USB or Bluetooth HID devices.
• Track vendor kernel advisories and deploy the first supported kernel update that includes the HID Magic Mouse fix.
• If patching is delayed, disable or restrict Bluetooth pairing and untrusted USB HID devices on affected systems.
• Blacklist or unload the Magic Mouse HID driver on systems that do not require Apple Magic Mouse support, after validating operational impact.
• Monitor kernel logs for OOM-killer events, repeated HID device connect/disconnect activity, and Magic Mouse driver activity until remediation is complete.
• Treat unexplained memory exhaustion on affected systems as potentially related, especially when correlated with peripheral activity.
• Because EPSS is very low and there is no known KEV or mature exploit, prioritize based on local access/peripheral exposure rather than internet exposure.