CVE-2026-46202: HID: appletb-kbd: run inactivity autodim from workqueues

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 backlightdevice->opslock via backlightdevicesetbrightness() -> mutexlock() from two different atomic contexts:

appletbinactivitytimer() is a struct timerlist 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> mightresched mutexlock backlightdevicesetbrightness appletbinactivitytimer calltimerfn runtimersoftirq

resetinactivitytimer() is called from appletbkbdhidevent() and appletbkbdinpevent(). 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 backlightdevicesetbrightness() directly to restore brightness, producing the same warning.

Both call sites hit the same mutexlock()-from-atomic bug. Fix them together by moving the blocking work onto the system workqueue:

Convert the inactivity timer from struct timerlist to struct delayedwork; the callback (appletbinactivitywork) now runs in process context where mutexlock() is legal. Add a dedicated struct workstruct restorebrightnesswork and have resetinactivitytimer() schedule it instead of calling backlightdevicesetbrightness() 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; resetinactivitytimer() keeps its name because it is invoked from input event paths that read naturally as "reset the inactivity timer".