LiveActive security incident?Get immediate response
CVE Record

CVE-2026-46213: HID: appletb-kbd: fix UAF in inactivity-timer cleanup path

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel use-after-free bug in the Apple Touch Bar keyboard/backlight driver cleanup path. During device or driver teardown, a timer can still touch a backlight object after it is freed. The public record does not provide CVSS, confirmed impact, or active exploitation evidence.

Executive priority

Treat as a targeted kernel maintenance issue, not an internet-wide emergency based on current evidence. Patch affected Linux endpoint builds in the next kernel update cycle, with higher priority for fleets running Linux on Apple hardware or custom kernels including this driver.

Technical view

The appletb-kbd inactivity timer can race with backlight device cleanup. One window deletes the final device reference before draining the timer; another allows a late HID event to re-arm the timer after deletion. Both lead to KASAN slab-use-after-free in __mutex_lock through backlight_device_set_brightness.

Likely exposure

Exposure appears limited to Linux systems with the affected HID appletb-kbd/backlight driver path, especially Apple hardware using this driver. Typical server and cloud fleets without this hardware or driver are less likely exposed. Confirm exact exposure against kernel version, enabled modules, and vendor stable commits.

Exploitation context

The supplied sources do not show active exploitation, public exploit code, KEV listing, or a complete impact assessment. The evidence is a kernel memory safety flaw observed through KASAN during teardown races involving concurrent unbind or late HID events.

Researcher notes

Do not assume broad exploitability from the record alone. The described bug is a teardown race involving timer_delete_sync, put_device, hid_hw_close, hid_hw_stop, and late HID .event callbacks. Validation should focus on code lineage and backports, not network exposure.

Mitigation direction

  • Apply kernel updates containing the referenced stable fixes when available for your distribution.
  • Check vendor kernel advisories for affected version mapping and backport status.
  • Prioritize systems running Linux on Apple hardware using appletb-kbd/backlight support.
  • Where practical, disable or avoid loading the affected driver until patched.
  • Do not deploy custom kernel changes without regression testing device teardown paths.

Validation and detection

  • Inventory kernels for appletb-kbd support and affected version ranges from vendor advisories.
  • Confirm whether Apple Touch Bar keyboard/backlight hardware is present in managed Linux endpoints.
  • Verify installed kernel includes one of the referenced stable fix commits or downstream backport.
  • Review kernel logs for KASAN or use-after-free reports around appletb-kbd or backlight teardown.
  • Run normal endpoint regression tests after updating kernels on affected Apple hardware.
Prepared
Confidence
medium
Sources
5

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2026-46213 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
4Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux38224c472a038fa9ccd4085511dd9f3d6119dbf9, 38224c472a038fa9ccd4085511dd9f3d6119dbf9, 38224c472a038fa9ccd4085511dd9f3d6119dbf9, 51720dee3a61ebace36c3dcdd0b4a488e0970f29, 6.15.6unaffected
LinuxLinux6.16, 0, 6.18.32, 7.0.9, 7.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.