CVE-2024-39508

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The race is reached only through local io_uring syscalls (`io_uring_setup(2)`/`io_uring_enter(2)`) on a ring the attacker owns, via `io_queue_iowq()` → `io_wq_enqueue()` → `io_wq_activate_free_worker()`. No network or adjacent-network data path touches `io_uring/io-wq.c`.

AC:LAttack complexity, low

The attacker controls both sides of the race: it creates the io-wq workers, forces async punting with `IOSQE_ASYNC`, and submits from multiple threads so that `io_wq_activate_free_worker()` walks `wq->free_list` on one CPU while a worker executes the non-atomic `worker->flags &= ~IO_WORKER_F_FREE` in `__io_worker_busy()` on another. The window can be hit repeatedly at no cost, exactly as KCSAN observed under ordinary load.

PR:LPrivileges required, low

Only an unprivileged local account is required — `io_uring_setup()` performs no capability check and `sysctl_io_uring_disabled` defaults to 0, permitting io_uring for all users; io-wq worker threads are created on demand for that user's own ring.

UI:NUser interaction, none

The attacking task performs every step itself — creating the ring, spawning submitter threads, and queueing async work — with no action required from any other user or administrator.

S:UScope, unchanged

The raced state and all its consequences live in the kernel's own io-wq bookkeeping for the calling task's ring; no VM, hypervisor, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

The raced field is the sole guard on `wq->free_list` membership — `io_worker_exit()` unlinks `worker->nulls_node` only `if (worker->flags & IO_WORKER_F_FREE)` before `kfree_rcu(worker, rcu)` — so an indeterminate value leaves a freed `io_worker` linked and read by `io_wq_activate_free_worker()` from other tasks, which after slab reuse discloses attacker-observable kernel heap contents through `worker->wq` and `worker->task`.

I:HIntegrity impact, high

The same stale-flag path lets other tasks operate on a freed `io_worker`: `io_worker_get()` performs `refcount_inc_not_zero` into a reallocated slab object and `wake_up_process(worker->task)` dereferences a sprayable pointer into the scheduler, yielding a write and control-flow primitive.

A:HAvailability impact, high

A wrong `IO_WORKER_F_BOUND` read makes `io_wq_activate_free_worker()` wake a worker from the other accounting class and return true, so `io_wq_enqueue()` skips `io_wq_create_worker()` and the queued work is left with no worker to run it — an indefinite hang of the io_uring request plus `acct->nr_running` imbalance, triggerable at will by an unprivileged user.