CVE-2026-46213
Received Received - Intake
Use-After-Free in Linux Kernel HID appletb-kbd Driver

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: HID: appletb-kbd: fix UAF in inactivity-timer cleanup path Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to both the probe close_hw error path and appletb_kbd_remove(), but the way it was wired in left the inactivity timer reachable during driver tear-down via two distinct windows. Window A -- put_device() before timer_delete_sync(): put_device(&kbd->backlight_dev->dev); timer_delete_sync(&kbd->inactivity_timer); The inactivity_timer softirq reads kbd->backlight_dev and calls backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a concurrent hid_appletb_bl unbind drops the last devm reference between these two calls, the backlight_device is freed and the mutex_lock() touches freed memory. Window B -- backlight cleanup before hid_hw_stop(): if (kbd->backlight_dev) { timer_delete_sync(...); put_device(...); } hid_hw_close(hdev); hid_hw_stop(hdev); Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run afterwards, so a late ".event" callback from the HID core (USB URB completion on real Apple hardware) can arrive after timer_delete_sync() drained the softirq but before put_device() drops the reference. That callback reaches reset_inactivity_timer(), which calls mod_timer() and re-arms the timer. The freshly re-armed timer can then fire on the about-to-be-freed backlight_device. Both windows produce the same KASAN slab-use-after-free: BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0 Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0 Call Trace: <IRQ> __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq handle_softirqs Allocated by task N: devm_backlight_device_register appletb_bl_probe Freed by task M: (concurrent hid_appletb_bl unbind path) Close both windows at once by reworking the tear-down in appletb_kbd_remove() and in the probe close_hw error path so that 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup, guaranteeing no further .event callback can fire and re-arm the timer, and 2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync() runs before put_device(), so the softirq is drained before the final reference is dropped.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free (UAF) bug in the Linux kernel's HID appletb-kbd driver related to the inactivity timer cleanup path.

The issue arises because the inactivity timer remains reachable during driver tear-down through two distinct timing windows, allowing the timer's softirq to access freed memory.

Specifically, the timer's callback reads data from a backlight device that may have been freed concurrently, leading to a use-after-free condition when the timer fires and tries to lock a mutex on freed memory.

The fix involves reordering the driver tear-down steps to ensure that the timer is deleted and drained before the backlight device reference is dropped, preventing the timer from firing on freed memory.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to access freed memory, leading to undefined behavior such as system crashes, kernel panics, or potential escalation of privileges.

Because it involves a use-after-free in kernel space, it could be exploited to destabilize the system or execute arbitrary code with kernel privileges, depending on the attacker's capabilities.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is a use-after-free bug in the Linux kernel's appletb-kbd driver related to the inactivity timer cleanup path.

To mitigate this vulnerability, ensure that your Linux kernel is updated to a version that includes the fix described in commit 38224c472a03.

The fix involves reworking the driver tear-down sequence so that the functions hid_hw_close() and hid_hw_stop() run before the backlight cleanup, preventing any late callbacks from re-arming the timer on freed memory.

Specifically, the timer_delete_sync() call should be executed before put_device() within the backlight device cleanup to drain the softirq before the final reference is dropped.

Therefore, immediate mitigation steps include applying the kernel patch or upgrading to a kernel version containing this fix.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability is a use-after-free bug in the Linux kernel's appletb-kbd driver related to the inactivity timer and backlight device cleanup. Detection typically involves monitoring kernel logs for KASAN (Kernel Address Sanitizer) slab-use-after-free errors.

You can check your system logs for messages similar to the following indicative of this vulnerability:

  • BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0
  • Read of size 8 at addr ... by task swapper/0/0
  • Call Trace including backlight_device_set_brightness and appletb_inactivity_timer

To detect this on your system, you can use the following commands to monitor kernel logs for such errors:

  • dmesg | grep -i 'slab-use-after-free'
  • journalctl -k | grep -i 'slab-use-after-free'
  • journalctl -k | grep -i 'appletb_inactivity_timer'

Additionally, enabling KASAN (Kernel Address Sanitizer) in your kernel configuration and running stress tests on the appletb-kbd driver may help in reproducing and detecting the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart