In the Linux kernel, the following vulnerability has been resolved:
HID: appleir: fix UAF on pending keyuptimer in remove()
appleirremove() runs hidhwstop() before timerdeletesync(). hidhwstop() synchronously unregisters the HID input device via hiddisconnect() -> hidinputdisconnect() -> inputunregisterdevice(), which drops the last reference and frees the underlying inputdev when no userspace handle holds it open.
keyuptick() reads appleir->inputdev and calls inputreportkey() / inputsync() on it. The timer is armed from appleirrawevent() 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 hidhwstop() 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 (rawevent) running during hidhwstop() can call modtimer() and re-arm the timer, which then fires after hidinputdisconnect() has freed inputdev. The same URB-completion window also lets rawevent() reach keyup(), keydown() and batteryflat() directly, all of which dereference appleir->input_dev.
Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleirremove() sets the flag under the lock and then shuts down the timer with timershutdownsync(), which both drains any in-flight callback and permanently disables further modtimer() calls. appleirrawevent() and keyuptick() 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 appleirrawevent() 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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64363.json"
}