CVE-2026-99103 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Fix unbound pool lifetime for pending pwqs
KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq():
BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318
CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450
Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610
Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790
Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock.
Remove the pwq from pending_pwqs before putting the pool.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel workqueue subsystem contains a critical use-after-free vulnerability affecting unbound worker pools during attribute changes. This flaw manifests when the system attempts to activate pending per-workqueue structures, specifically within the node_activate_pending_pwq function. The root cause lies in an incorrect ordering of operations during the cleanup phase of workqueue attribute modifications. When canceling inactive works, the kernel fails to properly decrement the active count via pwq_dec_nr_active(). This oversight allows a zero-reference-count per-workqueue structure to remain on the pending list even after its associated resources have been marked for release. Consequently, when the pool reference count drops to zero due to subsequent operations, the underlying worker_pool is freed using RCU mechanisms while the stale pointer to that pool remains accessible through the lingering workqueue structure.
This race condition leads to a slab-use-after-free error as detected by Kernel Address Sanitizer (KASAN). The vulnerability occurs because pwq_release_workfn attempts to put the associated pool before removing the per-workqueue structure from the pending list. If this operation reduces the pool's reference count to zero, the kernel schedules the pool for RCU-based deferred freeing. However, if another thread subsequently accesses the stale pointer in node_activate_pending_pwq and tries to acquire a spinlock on that now-freed memory region via _raw_spin_trylock, it triggers an invalid read access. This scenario highlights a classic concurrency bug where lifecycle management of interdependent kernel objects is not strictly sequenced, leading to use-after-free conditions that can potentially cause system crashes or unpredictable behavior depending on how the freed memory is reused by other subsystems.
From a security and standards perspective, this vulnerability aligns with CWE-416: Use After Free, which describes situations where software continues to use a pointer after it has been freed, leading to undefined behavior. In the context of kernel development, such flaws are particularly severe as they can lead to privilege escalation if an attacker can control the contents of the reclaimed memory slab or cause denial-of-service through system instability. The ATT&CK framework categorizes this type of issue under techniques related to exploitation for code execution or disruption, although in its raw form it is primarily a stability and integrity risk rather than a direct remote exploit vector unless combined with other vulnerabilities like heap spraying primitives.
The operational impact includes potential kernel panics, system hangs, or data corruption if the freed memory region is reallocated and accessed incorrectly. While this specific issue requires triggering workqueue attribute changes under concurrent conditions, it represents a significant reliability flaw in the core scheduling infrastructure of Linux. Mitigation involves applying the upstream kernel patch that corrects the ordering logic within pwq_release_workfn. The fix ensures that the per-workqueue structure is removed from the pending list before any attempt to release or put the associated worker pool reference count occurs. This guarantees that no stale pointers remain accessible after the underlying resources are deallocated, thereby eliminating the race condition and preventing use-after-free accesses during workqueue attribute modifications.