Cloudanix VulnDB

CVE-2026-99243

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recently discovered flaw in the Linux kernel can make the system freeze when certain high-speed input-output operations are used.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A missing memory barrier after set_bit() in io_wq_exit_start() allows a race on weakly ordered architectures between exit-bit publication and task-work queuing in io_queue_worker_create(); a creation entry can remain queued after io_wq_exit_workers() has begun, causing the exiting task to wait indefinitely on worker_done.

Why it matters to the business

Local workloads that rapidly create and destroy io_uring rings can trigger kernel-level hangs, resulting in application or system unavailability and requiring a reboot to recover.

How an attack unfolds

An attacker with local code execution repeatedly sets up and tears down io_uring rings while io-wq is exiting; on architectures without strong ordering the exit bit store is not visible before the task-works load, leaving a worker-creation entry queued and deadlocking the exit path.

How to fix it

Upgrade the Linux kernel to a version containing the barrier after set_bit() in io_wq_exit_start(); rebuild and reboot affected systems.

How to confirm the fix worked

Inspect the kernel source for the added smp_mb__after_atomic() (or equivalent) immediately following the set_bit() call that sets IO_WQ_BIT_EXIT; confirm the fix appears in the running kernel via /proc/version or kernel package metadata.

Typical attack path

  1. Obtain local execution
  2. Create multiple io_uring rings
  3. Trigger concurrent ring teardown and io-wq exit
  4. Exploit missing barrier to leave worker creation queued
  5. Cause indefinite wait on worker_done

How to detect it

Examine kernel stack traces, dmesg, and core dumps for threads blocked inside io_wq_exit_workers() or waiting on worker_done while io_uring rings are being torn down; correlate with process activity involving io_uring setup/teardown.

What your security team should do

  • Prioritize kernel updates on all systems exposing io_uring to untrusted local users
  • Restrict io_uring usage via seccomp or LSM policies where feasible
  • Monitor kernel crash and hang reports for io_wq_exit_workers signatures

The record

In the Linux kernel, the following vulnerability has been resolved: io-wq: order the exit bit against worker creation task work io_wq_exit_workers() cancels task work for queued worker creation with task_work_cancel_match(). That has a plain load of task->task_works. io_queue_worker_create() adds the new entry and tests IO_WQ_BIT_EXIT to cancel it if the workqueue is already on its way out. That must be ordered. task_work_add() has a full barrier via cmpxchg(). But io_wq_exit_start() sets the bit with set_bit() which doesn't have any memory ordering. So afaict, on weakly ordered architectures the exiting task may load task_works before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with worker_refs and the exiting task waits on worker_done indefinitely. If the task still has rings then io_uring_del_tctx_node() provides the barrier via test_and_set_bit() in io_wq_set_exit_on_idle(). When it has closed all rings though that barrier is gone. Add the barrier after the set_bit().

Affected packages

Ecosystem Package Introduced Fixed