CVE-2026-23113: Linux Kernel io_uring DoS Vulnerability

CVE-2026-23113 Overview

A vulnerability has been identified in the Linux kernel's io_uring/io-wq subsystem related to improper handling of the IO_WQ_BIT_EXIT flag during work queue processing. The flaw occurs because the exit check is performed before running pending work items rather than inside the work run loop, which can lead to extended processing times when handling large I/O operations and cause tasks to become blocked for extended periods.

Critical Impact
This vulnerability can cause tasks to become blocked for over 140 seconds during io-wq exit, triggering hung task warnings and potentially impacting system responsiveness when processing large queued I/O operations.

Affected Products

Linux kernel (io_uring/io-wq subsystem)
Systems using io_uring for asynchronous I/O operations
Linux systems with access to /dev/msr* device files

Discovery Timeline

2026-02-14 - CVE CVE-2026-23113 published to NVD
2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23113

Vulnerability Analysis

The vulnerability exists in the io_uring work queue (io-wq) implementation within the Linux kernel. The issue stems from the timing of when the IO_WQ_BIT_EXIT flag is checked during work queue processing. Currently, the check occurs before running pending work items, which is normally acceptable for work items that either block (creating a new worker for other items) or complete quickly.

However, problematic behavior emerges when processing large I/O operations, particularly with device files that don't support the ->read_iter() interface. In such cases, loop_rw_iter() handles the operations, and each read can take an exceptionally long time. The specific case identified involves queuing multiple large reads (2GB - 4096 bytes each) against /dev/msr* files, where each read returns 16MB of data and takes approximately 20 seconds to complete.

When a series of these large reads are queued and the io_uring ring is subsequently exited, the worker must process the entire chain before recognizing the exit condition. This can easily exceed timeout thresholds, such as syzbot's 140-second uninterruptible sleep timeout, causing hung task warnings even though the system is functioning correctly—just slowly.

Root Cause

The root cause is the placement of the IO_WQ_BIT_EXIT check outside the io_worker_handle_work() loop. The exit flag should be checked inside the work run loop so that when the first work item completes after an exit request, the remaining queued items can be cancelled immediately rather than processed sequentially.

The problematic flow occurs in:

io_wq_exit_workers() at io_uring/io-wq.c:1328
io_wq_put_and_exit() at io_uring/io-wq.c:1356
io_uring_clean_tctx() at io_uring/tctx.c:203

Attack Vector

The vulnerability can be triggered through local access by a user who can submit io_uring operations. The attack vector involves:

Opening a file descriptor for a device that doesn't support ->read_iter() (such as /dev/msr*)
Queuing multiple large read operations (e.g., 2GB - 4096 bytes each) through io_uring
Initiating an exit of the io_uring ring after queuing the operations
The kernel worker becomes blocked processing the queue, potentially exceeding system timeout thresholds

This can result in denial of service conditions through resource exhaustion, as kernel workers become tied up processing the queued operations even after the application has requested termination.

Detection Methods for CVE-2026-23113

Indicators of Compromise

Kernel log messages showing tasks blocked for extended periods (e.g., "blocked for more than 143 seconds")
Hung task warnings referencing io_wq_exit_workers or io_wq_put_and_exit in the call trace
Processes stuck in uninterruptible sleep (D state) related to io_uring operations
System unresponsiveness when applications using io_uring are terminating

Detection Strategies

Monitor kernel logs for hung task timeout messages containing io_uring/io-wq.c references
Implement alerting on processes in D state with stack traces showing io_wq_exit_workers
Track io_uring operations against device files that don't support ->read_iter() interface
Deploy kernel tracing (ftrace/eBPF) to monitor IO_WQ_BIT_EXIT flag handling patterns

Monitoring Recommendations

Configure appropriate hung_task_timeout_secs values to balance between false positives and legitimate issue detection
Monitor system call latency for io_uring-related operations during process termination
Implement watchdog monitoring for processes using io_uring with large I/O operations
Review application behavior patterns that queue multiple large reads before exit

How to Mitigate CVE-2026-23113

Immediate Actions Required

Apply the kernel patches from the official kernel git repository
Review applications using io_uring for potential exposure to this issue
Consider restricting access to /dev/msr* and similar device files that don't support ->read_iter()
Implement process monitoring to detect and alert on hung io_uring workers

Patch Information

The fix involves checking the IO_WQ_BIT_EXIT flag inside the io_worker_handle_work() loop. When the first work item completes after an exit has been requested, io-wq will cancel the remaining queued items rather than processing them all sequentially.

Official patches are available from the kernel git repository:

Workarounds

Temporarily disable hung task timeout warnings by setting echo 0 > /proc/sys/kernel/hung_task_timeout_secs (note: this hides the symptom but doesn't address the underlying issue)
Restrict access to device files that trigger the slow code path through file permissions
Limit the size of individual I/O operations submitted through io_uring where possible
Consider using alternative I/O mechanisms for applications that queue large reads to problematic device types

bash

# Configuration example
# Temporarily increase hung task timeout (not a fix, but prevents false alerts)
echo 300 > /proc/sys/kernel/hung_task_timeout_secs

# Restrict access to msr devices to root only
chmod 600 /dev/cpu/*/msr

# Apply kernel update on Debian/Ubuntu
apt update && apt upgrade linux-image-$(uname -r)

# Apply kernel update on RHEL/CentOS
yum update kernel