CVE-2026-64363

Awaiting Analysis Awaiting Analysis - Queue

Use-After-Free in Linux Kernel HID AppleIR Driver

Publication date: 2026-07-25

Last updated on: 2026-08-11

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-07-25

Last Modified

2026-08-11

Generated

2026-08-14

AI Q&A

2026-07-25

EPSS Evaluated

2026-08-13

NVD

CVE-2026-64363

EUVD

EUVD-2026-48907

Affected Vendors & Products

Vendor	Product	Version / Range
apple	appleir	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This is a use-after-free (UAF) vulnerability in the Linux kernel's HID driver for Apple IR devices. The issue occurs when the appleir_remove() function stops the device before properly cleaning up a timer, leading to a timer firing after the device's memory has been freed. This can cause crashes or other undefined behavior.

Detection Guidance

This vulnerability is specific to the Linux kernel's HID driver for Apple IR devices. Detection requires checking if the affected driver (appleir) is loaded and examining kernel logs for related errors. Commands like 'lsmod | grep appleir' can confirm if the module is loaded. Kernel logs may show use-after-free errors related to input_dev during device disconnection.

Impact Analysis

If exploited, this vulnerability could lead to system instability, crashes, or potential privilege escalation. It specifically affects systems using Apple IR devices, potentially disrupting input functionality or causing kernel panics.

Compliance Impact

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's HID driver for Apple IR devices. It does not directly relate to data handling, storage, or access controls that are typically governed by GDPR or HIPAA. Compliance impact would depend on whether this flaw could lead to unauthorized data access or system instability in environments handling sensitive data.

Mitigation Strategies

Apply the kernel patch that reorders cleanup steps and introduces a 'removing' flag to prevent UAF. Update to a kernel version containing the fix. If immediate patching is not possible, consider disabling the appleir module via 'modprobe -r appleir' if not actively used.

Hi! I’m here to help you understand CVE-2026-64363. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70