Cloudanix VulnDB

CVE-2026-99103

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug in managing background task queues could let an attacker crash the whole system or run code with full privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free of an unbound worker_pool in node_activate_pending_pwq() caused by canceling the last inactive work without calling pwq_dec_nr_active(), leaving an empty pwq on pending_pwqs whose pool can be RCU-freed before the pwq is removed.

Why it matters to the business

Kernel crashes or potential privilege escalation on Linux systems performing workqueue attribute changes or flush operations, increasing downtime and compromise risk on servers and embedded devices.

How an attack unfolds

An attacker triggers wq_nice_store or apply_workqueue_attrs operations that allocate pwqs, then arranges for the final work to be canceled so the pwq reaches zero refcount while still on pending_pwqs; the subsequent put_unbound_pool RCU-frees the pool, and later pwq_dec_nr_in_flight dereferences the freed pool lock.

How to fix it

Apply the upstream workqueue fix that removes the pwq from pending_pwqs before calling put_unbound_pool; rebuild and deploy the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting pwq_release_workfn and node_activate_pending_pwq in the kernel source; re-run KASAN-enabled workloads that previously triggered the slab-use-after-free.

Typical attack path

  1. Invoke workqueue attribute or nice-value changes to allocate unbound pwqs
  2. Cancel or complete the last work item on a pwq so its refcount hits zero while it remains on pending_pwqs
  3. Wait for RCU grace period to free the worker_pool
  4. Trigger process_one_work on the now-dangling pwq to reach node_activate_pending_pwq and trylock the freed pool

How to detect it

Search kernel logs and dmesg for KASAN slab-use-after-free reports mentioning workqueue functions; correlate with processes performing wq_nice_store or flush operations.

  • BUG: KASAN: slab-use-after-free in _raw_spin_trylock
  • pwq_dec_nr_in_flight
  • node_activate_pending_pwq
  • put_unbound_pool
  • pwq_release_workfn

What your security team should do

  • Immediately update production kernels once the fix is released in distro packages
  • Enable KASAN or similar debug options on test systems to validate the fix
  • Review workloads that frequently change workqueue attributes or perform flushes

The record

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.

Affected packages

Ecosystem Package Introduced Fixed