CVE-2026-43140

What it actually does

CVE-2026-43140 is a Linux kernel denial-of-service flaw in the HID Magic Mouse driver. A fake USB device can impersonate an Apple Magic Mouse and provide a crafted HID report descriptor that prevents the driver's input_mapping() path from initializing the expected msc->input structure. When the driver later assumes that structure is valid, it can dereference a NULL pointer and crash the kernel. The impact is availability loss only: successful exploitation can panic or oops the affected system, but it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

An attacker with local access or the ability to present a malicious USB HID device to a Linux system can crash that system, causing service interruption, workstation downtime, failed jobs, or disruption to embedded, kiosk, lab, or server environments where USB device exposure is possible. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity indicated, so broad internet-scale urgency is low; however, systems that allow untrusted USB devices or USB device emulation should treat it as a practical local availability risk.

How an attack unfolds

An attacker prepares a USB device or USB-emulation platform that identifies itself as a Magic Mouse-compatible HID device but supplies a nonstandard report descriptor. When the device is attached to an affected Linux host, the kernel binds it to the Magic Mouse HID driver. Because the crafted descriptor avoids the path that normally initializes the driver's input object, the driver keeps msc->input as NULL. Later, during device configuration or report handling, the driver references that missing object and triggers a kernel crash. The attacker’s objective is to force a denial of service rather than gain persistence or execute commands.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the HID Magic Mouse driver. No exact fixed package versions were provided in the input, so administrators should map this CVE to their distribution advisory and upgrade to the vendor-designated fixed kernel build. Where immediate patching is not possible, reduce exposure by blocking untrusted USB devices, disabling USB ports where operationally feasible, enforcing USB device control policies, and preventing untrusted USB passthrough into virtual machines. If Magic Mouse support is not required, consider disabling or blacklisting the affected driver/module according to distribution policy, while validating that doing so does not disrupt legitimate input devices.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the fixed version listed by the operating system vendor for this CVE, not merely that an updated package is installed on disk. Reboot into the patched kernel where required. Check vendor security advisories, kernel changelogs, or package metadata for the Magic Mouse HID fix described as rejecting devices when msc->input is missing. Validate exposure reduction by confirming USB device-control policy is active, untrusted USB HID devices are blocked, and the Magic Mouse HID driver is disabled where not needed. For high-assurance validation, use a controlled test host to attach a malformed Magic Mouse-emulating USB device and confirm the patched kernel rejects the device without crashing.

Typical attack path

1. Gain local physical access to a Linux system or obtain another way to present a USB HID device to it, such as USB gadget emulation, malicious peripheral hardware, or device passthrough.
2. Configure a fake USB HID device to impersonate a Magic Mouse-class device.
3. Send a crafted HID report descriptor that prevents normal input_mapping() initialization in the Magic Mouse driver.
4. Allow the affected kernel to bind the device to the hid_magicmouse/magicmouse driver path.
5. Trigger driver configuration or input handling that dereferences the missing input structure.
6. Cause a kernel oops or panic, resulting in system crash, reboot, or loss of availability.

How to detect it

To determine whether exploitation may have already occurred, review logs that survive reboots and kernel crashes, including systemd journal, syslog, kern.log, dmesg snapshots, kdump/vmcore records, crash dump metadata, endpoint telemetry, and physical access or USB-control logs. Look for a sequence of events where a newly attached USB HID device is identified as a Magic Mouse or Apple-like HID peripheral, followed shortly by hid_magicmouse or magicmouse driver messages, a NULL pointer dereference, kernel oops, panic, watchdog reboot, or unexplained crash. Correlate timestamps with physical access records, USB device-control alerts, VM USB passthrough events, and any repeated attach/detach activity. Because this vulnerability causes a crash rather than persistence, indicators are likely to be transient and log-based; absence of logs after a crash does not fully rule out exploitation.

• hid_magicmouse
• magicmouse
• Magic Mouse
• Apple Magic Mouse
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• Unable to handle kernel NULL pointer dereference
• usbcore: registered new interface driver magicmouse
• input: Magic Mouse
• HID: magicmouse
• usb *: new full-speed USB device
• usb *: new high-speed USB device
• hid-generic
• usbhid
• kdump
• vmcore

What your security team should do

• Prioritize patching Linux systems that are physically accessible, used in shared workspaces, kiosks, labs, manufacturing environments, classrooms, or other locations where untrusted USB devices can be attached.
• Obtain the fixed kernel version from the relevant Linux distribution advisory and schedule reboot into the patched kernel.
• Temporarily restrict untrusted USB devices and USB passthrough until affected systems are patched.
• Disable or blacklist Magic Mouse driver support on systems that do not require it, after compatibility testing.
• Review recent kernel crash, kdump, journald, syslog, and USB device attachment logs for suspicious Magic Mouse-like HID devices followed by kernel oops, panic, or reboot events.
• Ensure endpoint, server, and hypervisor hardening baselines include controls for removable USB HID devices.
• Because EPSS is very low and there is no KEV listing or known ransomware use, treat this as a targeted/local denial-of-service issue rather than an externally exploitable emergency, unless the environment has high USB exposure.