CVE-2026-64363

What it actually does

This is a use-after-free race in the Linux kernel HID appleir driver during device removal. When an Apple infrared HID device is disconnected, the driver can unregister and free the input device while a pending key-release timer or USB completion path can still dereference the freed input_dev structure. A racing key event, key-repeat event, flat-battery report, timer callback, or device disconnect can therefore cause kernel memory corruption. The most likely practical outcome is a kernel crash or system instability; depending on kernel configuration, memory layout, and attacker control over timing and heap reuse, privilege escalation or arbitrary kernel code execution may be theoretically possible, but no public exploit maturity is currently indicated.

Why it matters to the business

Systems using vulnerable Linux kernels with the appleir HID driver may be exposed to local or physically adjacent denial-of-service risk if an attacker can interact with or emulate a supported Apple infrared HID device and trigger the disconnect race. Because this is kernel-level memory corruption, successful exploitation could interrupt workloads, crash endpoints or servers, and in worst-case scenarios compromise the operating system. Current public risk signals are low: it is not listed in CISA KEV, is not associated with ransomware use, has low EPSS, and has no known exploit maturity, but kernel memory-safety flaws should still be addressed through normal kernel update cycles.

How an attack unfolds

An attacker needs a way to cause the vulnerable appleir driver to process HID input and then tear down the device while deferred work is still pending. In a realistic scenario, the attacker connects or emulates a compatible Apple infrared HID device, sends keydown or key-repeat reports that arm the key_up_timer, and then rapidly disconnects the device or otherwise causes driver removal. During removal, the HID stack may unregister and free the input device before the timer or a USB completion path has fully stopped. If the timer fires or a raw event handler runs after the input device has been freed, the driver dereferences stale kernel memory. This can crash the kernel and may create a kernel memory-corruption primitive if an attacker can reliably shape timing and heap reuse. There is no current indication of broad remote exploitation, ransomware use, or named threat actor exploitation.

How to fix it

Apply a Linux kernel update that includes the appleir driver fix introducing a removal flag, synchronized teardown, and timer_shutdown_sync() protection for the key-up timer. If vendor fixed kernel package versions are available for the distribution, upgrade to those exact versions or later. If immediate patching is not possible and Apple infrared HID support is not required, reduce exposure by disabling or blacklisting the appleir driver where operationally safe, restricting physical/USB access to systems, disabling unauthorized USB HID devices through device-control policy, and limiting access to virtualization or passthrough features that can present HID devices to the host. Reboot into the updated kernel after patching; merely installing kernel packages is insufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, includes the vendor fix for the appleir HID use-after-free. Validate by checking the active kernel version with uname -r and comparing it with the distribution's security advisory or patched kernel build. Where source or symbols are available, confirm the appleir driver contains removal-state guarding and uses timer_shutdown_sync() during removal. Check whether the appleir module is present or loaded using lsmod, modinfo, or kernel configuration data. If mitigation was chosen instead of patching, verify the driver cannot autoload and that compatible HID devices are blocked by policy. After remediation, reboot and confirm the vulnerable kernel is no longer running.

Typical attack path

1. Gain local physical access, USB-level access, or the ability to emulate a compatible Apple infrared HID device presented to a vulnerable Linux system.
2. Trigger appleir input handling by sending keydown, key-repeat, or related HID reports that arm the driver's delayed key-release timer.
3. Force or race device removal, such as by disconnecting the device or resetting the USB/HID path shortly after a key event.
4. Cause the pending timer callback or USB completion path to execute after the HID input device has been unregistered and freed.
5. Trigger a use-after-free dereference in kernel context, resulting in a kernel crash or potentially exploitable memory corruption.

How to detect it

Historical exploitation detection is difficult because this is a kernel race condition and may leave only crash or hardware-event artifacts. Review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry for appleir driver activity followed by kernel oops, panic, general protection fault, use-after-free, KASAN, slab, timer, HID, or input subsystem errors. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, systemd journal persistence, kdump/vmcore artifacts, crash reporting systems, EDR kernel-crash telemetry, and USB device audit logs. Look for repeated connect/disconnect or reset events for Apple infrared HID devices, especially immediately after key events or before a kernel crash. If KASAN or other kernel sanitizers are enabled, search for use-after-free reports involving appleir_remove(), appleir_raw_event(), key_up_tick(), input_report_key(), input_sync(), hid_hw_stop(), hidinput_disconnect(), or input_unregister_device(). Because there are no public actor-specific indicators, absence of these artifacts does not prove the flaw was not triggered; prioritize correlation of HID device churn with kernel crashes.

• appleir
• appleir_remove
• appleir_raw_event
• key_up_tick
• input_report_key
• input_sync
• hid_hw_stop
• hidinput_disconnect
• input_unregister_device
• timer_shutdown_sync
• key_up_timer
• HID: appleir
• BUG: KASAN: use-after-free
• use-after-free in key_up_tick
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• usb disconnect
• USB disconnect
• hid-generic
• input: Apple

What your security team should do

• Prioritize patching Linux endpoints or systems where users can attach USB devices, where HID passthrough is allowed, or where compatible Apple infrared hardware may be present.
• Confirm reboot completion after kernel updates so systems are actually running the fixed kernel.
• If patching is delayed, blacklist or disable the appleir driver where not needed and enforce USB/HID device-control restrictions.
• Review kernel crash, USB, and HID logs for suspicious disconnect races, repeated appleir initialization/removal, or crashes shortly after HID input events.
• Treat any unexplained kernel oops, panic, or memory-corruption report involving appleir, hidinput, input_report_key, or timer callbacks as potentially relevant and preserve logs for forensic review.
• Monitor vendor kernel advisories for exact fixed package versions, because fixed versions were not provided in the input data.