FKIE_CVE-2026-46202
Vulnerability from fkie_nvd - Published: 2026-05-28 10:16 - Updated: 2026-05-28 13:44
Severity
Summary
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".
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: appletb-kbd: run inactivity autodim from workqueues\n\nThe autodim code in hid-appletb-kbd takes backlight_device-\u003eops_lock\nvia backlight_device_set_brightness() -\u003e mutex_lock() from two\ndifferent atomic contexts:\n\n * appletb_inactivity_timer() is a struct timer_list callback, so it\n runs in softirq context. Every expiry triggers\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591\n Call Trace:\n \u003cIRQ\u003e\n __might_resched\n __mutex_lock\n backlight_device_set_brightness\n appletb_inactivity_timer\n call_timer_fn\n run_timer_softirq\n\n * reset_inactivity_timer() is called from appletb_kbd_hid_event() and\n appletb_kbd_inp_event(). On real USB hardware these run in\n softirq/IRQ context (URB completion and input-event dispatch).\n When the Touch Bar has already been dimmed or turned off, the\n reset path calls backlight_device_set_brightness() directly to\n restore brightness, producing the same warning.\n\nBoth call sites hit the same mutex_lock()-from-atomic bug. Fix them\ntogether by moving the blocking work onto the system workqueue:\n\n * Convert the inactivity timer from struct timer_list to\n struct delayed_work; the callback (appletb_inactivity_work) now\n runs in process context where mutex_lock() is legal.\n * Add a dedicated struct work_struct restore_brightness_work and have\n reset_inactivity_timer() schedule it instead of calling\n backlight_device_set_brightness() directly.\n\nCancel both works synchronously during driver tear-down alongside the\nexisting backlight reference drop.\n\nThe semantics are unchanged (same delays, same state transitions on\ndim, turn-off and user activity); only the execution context of the\nsleeping call changes. The timer field and callback are renamed to\nmatch their new type; reset_inactivity_timer() keeps its name because\nit is invoked from input event paths that read naturally as \"reset\nthe inactivity timer\"."
}
],
"id": "CVE-2026-46202",
"lastModified": "2026-05-28T13:44:01.663",
"metrics": {},
"published": "2026-05-28T10:16:35.860",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1654e53349d4e657b331de354313461f401f5063"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2473a334c292af257ef68e33bc7760f4a8251812"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5c0830323689ef15224f0025276176988861b3b0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…