CVE-2026-23473: Linux Kernel Race Condition Vulnerability

CVE-2026-23473 Overview

A race condition vulnerability exists in the Linux kernel's io_uring subsystem, specifically in the poll mechanism handling multishot receive operations. When a socket send and shutdown() occur back-to-back, both operations fire wake-ups before the receiver's task_work has an opportunity to execute. This race condition can cause multishot recv operations to miss the EOF (End-of-File) signal, potentially leading to a denial of service condition where the operation hangs indefinitely.

Critical Impact

Applications using io_uring's multishot recv functionality may experience indefinite hangs when socket shutdown events are lost due to the poll reference counting race condition.

Affected Products

• Linux kernel with io_uring subsystem enabled
• Systems utilizing multishot recv operations via io_uring
• Network applications leveraging io_uring for asynchronous socket I/O

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-23473 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-23473

Vulnerability Analysis

This vulnerability is a classic race condition in the Linux kernel's io_uring poll subsystem. The flaw manifests when handling concurrent socket events during multishot receive operations.

When a socket performs a send() followed immediately by a shutdown(), both operations generate wake-up events that arrive before the receiver's task_work callback executes. The first wake-up acquires poll ownership by setting poll_refs=1, while the second wake-up increments this counter to 2.

When io_poll_check_events() subsequently runs, it invokes io_poll_issue() which performs a recv operation that reads the data and returns IOU_RETRY. The event loop then drains all accumulated poll references using atomic_sub_return(2), which returns 0 and causes the loop to exit. The critical issue is that only the first event (the data receive) was actually consumed, while the second event (the shutdown notification) is silently lost.

Since shutdown represents a persistent state change that does not generate additional wake-ups, no further notifications will arrive. This causes the multishot recv operation to hang indefinitely, waiting for an event that will never come.

Root Cause

The root cause lies in the poll reference counting mechanism within io_poll_check_events(). The function drains all accumulated poll references in a single operation without ensuring each corresponding event has been properly processed. When multiple wake-ups occur before the handler runs, the loop consumes all references but only processes a single event iteration, causing subsequent events like HUP (hangup) signals to be missed.

Attack Vector

The vulnerability can be triggered through normal socket operations that cause concurrent wake-up events. An attacker with the ability to influence socket timing could potentially exploit this to cause denial of service conditions in applications relying on io_uring multishot recv operations.

The attack scenario involves:

1. An application using io_uring's multishot recv to monitor a socket
2. Rapid succession of data transmission followed by socket shutdown
3. Both events triggering wake-ups before task_work execution
4. The poll reference draining mechanism missing the shutdown event
5. The recv operation hanging indefinitely, consuming kernel resources

Detection Methods for CVE-2026-23473

Indicators of Compromise

• Hung processes with io_uring operations visible in /proc/<pid>/fdinfo
• Stalled multishot recv operations that fail to terminate after socket closure
• Increased system resource consumption from processes waiting on io_uring completions
• Application-level timeouts or unresponsiveness in io_uring-based network services

Detection Strategies

• Monitor for processes with abnormally long-running io_uring operations using io_uring_show_fdinfo output
• Implement application-level health checks that verify socket operations complete within expected timeframes
• Use kernel tracing (ftrace/bpftrace) to monitor io_poll_check_events behavior and poll reference counts
• Deploy watchdog mechanisms for critical network services using io_uring multishot recv

Monitoring Recommendations

• Enable kernel auditing for io_uring system calls to track operation patterns
• Implement alerting for processes exceeding expected socket operation durations
• Monitor system resource utilization for signs of resource exhaustion from hung operations
• Review application logs for timeout errors related to socket receive operations

How to Mitigate CVE-2026-23473

Immediate Actions Required

• Apply the official kernel patches from the stable kernel tree
• Restart affected services after kernel update to ensure clean io_uring state
• Consider temporarily switching to non-multishot recv operations for critical applications
• Implement application-level timeouts as a defensive measure

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix modifies the poll event handling loop to specifically check for HUP conditions and ensures additional loop iterations occur when more than a single poll activation is pending. This prevents the shutdown event from being silently dropped.

Patches are available through the following kernel commits:

• Kernel Git Commit 0f4ce79
• Kernel Git Commit a68ed2d
• Kernel Git Commit bf33554

Workarounds

• Avoid using multishot recv operations in io_uring until patched kernel is deployed
• Implement application-level socket state monitoring with explicit shutdown detection
• Use traditional poll/epoll mechanisms as a temporary alternative for critical services
• Deploy socket operation timeouts to prevent indefinite hangs from impacting service availability

# Check current kernel version
uname -r

# Verify io_uring is in use on the system
lsof 2>/dev/null | grep io_uring

# Monitor for hung io_uring operations
cat /proc/$(pgrep -f your_app)/fdinfo/* | grep -A 20 io_uring