CVE-2026-46202
Received Received - Intake
Race Condition in Linux Kernel HID Appletb Keyboard 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: run inactivity autodim from workqueues The autodim code in hid-appletb-kbd takes backlight_device->ops_lock via backlight_device_set_brightness() -> mutex_lock() from two different atomic contexts: * appletb_inactivity_timer() is a struct timer_list callback, so it runs in softirq context. Every expiry triggers BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 Call Trace: <IRQ> __might_resched __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq * reset_inactivity_timer() is called from appletb_kbd_hid_event() and appletb_kbd_inp_event(). On real USB hardware these run in softirq/IRQ context (URB completion and input-event dispatch). When the Touch Bar has already been dimmed or turned off, the reset path calls backlight_device_set_brightness() directly to restore brightness, producing the same warning. Both call sites hit the same mutex_lock()-from-atomic bug. Fix them together by moving the blocking work onto the system workqueue: * Convert the inactivity timer from struct timer_list to struct delayed_work; the callback (appletb_inactivity_work) now runs in process context where mutex_lock() is legal. * Add a dedicated struct work_struct restore_brightness_work and have reset_inactivity_timer() schedule it instead of calling backlight_device_set_brightness() directly. Cancel both works synchronously during driver tear-down alongside the existing backlight reference drop. The semantics are unchanged (same delays, same state transitions on dim, turn-off and user activity); only the execution context of the sleeping call changes. The timer field and callback are renamed to match their new type; reset_inactivity_timer() keeps its name because it is invoked from input event paths that read naturally as "reset the inactivity timer".
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
CVE-2026-46202
EUVD
EUVD-2026-32829
Affected Vendors & Products
Currently, no data is known.
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 exists in the Linux kernel's hid-appletb-kbd driver related to the handling of the Touch Bar's backlight brightness. The issue arises because the code attempts to acquire a mutex lock (ops_lock) from two different atomic contexts where sleeping is not allowed. Specifically, the inactivity autodim code calls backlight_device_set_brightness(), which tries to lock a mutex from softirq or IRQ contexts, leading to a BUG due to calling a sleeping function from an invalid context.

The problem occurs in two places: the inactivity timer callback (appletb_inactivity_timer) running in softirq context, and the reset_inactivity_timer function called from input event paths also running in atomic contexts. Both call backlight_device_set_brightness() directly, causing the mutex_lock-from-atomic bug.

The fix involved moving the blocking work to the system workqueue by converting the timer to delayed_work and scheduling brightness restoration work asynchronously. This ensures the mutex_lock() call happens in process context where sleeping is allowed, preventing the invalid context bug.


How can this vulnerability impact me? :

This vulnerability can cause kernel warnings and potentially kernel instability or crashes due to improper locking in atomic contexts. Specifically, calling a sleeping function like mutex_lock() from an atomic context can lead to BUG messages and may destabilize the system or cause unexpected behavior in the Touch Bar backlight functionality.

While the semantics of the backlight dimming and brightness restoration remain unchanged, the bug could affect system reliability and user experience by triggering kernel errors during normal input or inactivity events.


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

This vulnerability manifests as a kernel BUG triggered by a sleeping function called from an invalid atomic context. Detection involves monitoring kernel logs for specific BUG messages related to mutex_lock() called from atomic contexts in the hid-appletb-kbd driver.

You can check your system logs (e.g., dmesg or /var/log/kern.log) for messages similar to:

  • BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
  • Call Trace involving backlight_device_set_brightness and appletb_inactivity_timer or reset_inactivity_timer

Suggested commands to detect this issue include:

  • dmesg | grep 'BUG: sleeping function called from invalid context'
  • journalctl -k | grep 'backlight_device_set_brightness'
  • grep -i 'appletb_inactivity_timer' /var/log/kern.log

What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by changing the execution context of the backlight brightness adjustment calls from atomic contexts to process context using workqueues.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix which converts the inactivity timer from struct timer_list to struct delayed_work and schedules brightness restoration work on a system workqueue.
  • Avoid using affected versions of the hid-appletb-kbd driver until patched.
  • If updating is not immediately possible, monitor kernel logs for the BUG messages and consider disabling the affected driver or related features temporarily to prevent the bug from triggering.

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