CVE-2026-23394: Linux Kernel Race Condition Vulnerability

CVE-2026-23394 Overview

A race condition vulnerability exists in the Linux kernel's Unix domain socket (af_unix) garbage collection (GC) mechanism. The vulnerability occurs when MSG_PEEK operations interfere with the GC process, potentially causing the GC to incorrectly purge the receive queue of an active socket. This issue was previously addressed in commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"), but was reintroduced after the GC algorithm was replaced and the locking mechanism in unix_peek_fds() was removed.

Critical Impact

The race condition can cause legitimate socket data to be garbage collected while still in use, potentially leading to data loss or denial of service conditions in applications relying on Unix domain socket communication.

Affected Products

• Linux kernel with af_unix socket support
• Systems utilizing Unix domain sockets with MSG_PEEK operations
• Kernel versions between the GC algorithm replacement and the fix commits

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23394 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23394

Vulnerability Analysis

The vulnerability stems from a race condition between the garbage collection thread and user-space MSG_PEEK operations on Unix domain sockets. The core issue is that MSG_PEEK increments a file's reference count without any synchronization with the GC mechanism.

When the GC evaluates whether a socket is "dead" using unix_vertex_dead(), it compares the file reference count against the number of inflight file descriptors. If these values match, the GC concludes the socket is unreachable and can be collected. However, MSG_PEEK silently bumps the file refcount, invalidating the GC's earlier evaluation.

The race manifests in a Strongly Connected Component (SCC) containing two sockets (sk-A and sk-B):

1. GC evaluates unix_vertex_dead(sk-A) as true based on current refcounts
2. A user thread performs recv(sk-B, MSG_PEEK), incrementing sk-A's refcount
3. The user thread calls close(sk-B), decrementing sk-B's refcount
4. GC evaluates unix_vertex_dead(sk-B) as true
5. GC incorrectly concludes both sockets are dead and purges them

Root Cause

The root cause is the lack of synchronization between the MSG_PEEK operation's file reference count manipulation and the garbage collector's dead socket detection logic. When the locking dance in unix_peek_fds() was removed during the GC algorithm replacement, the protection against this race condition was lost. The file refcount can be modified by MSG_PEEK without any visibility to the concurrent GC thread, leading to incorrect dead socket determinations.

Attack Vector

The vulnerability is exploitable locally by any user with access to Unix domain sockets. An attacker could potentially craft a sequence of MSG_PEEK and close operations to trigger the race condition, causing the GC to incorrectly purge socket receive queues. This could result in denial of service by corrupting inter-process communication channels or causing data loss in applications relying on Unix domain socket messaging.

The fix introduces a seqcount_t mechanism to signal when MSG_PEEK occurs, allowing the GC to detect the race and defer collection to a subsequent run. This approach avoids locking overhead on the MSG_PEEK path while maintaining correctness.

Detection Methods for CVE-2026-23394

Indicators of Compromise

• Unexpected data loss or message corruption in applications using Unix domain sockets
• Application crashes or hangs related to socket operations with MSG_PEEK
• Kernel log messages indicating socket garbage collection anomalies
• Increased occurrences of ECONNRESET or similar socket errors in affected applications

Detection Strategies

• Monitor kernel logs for af_unix subsystem warnings or errors related to garbage collection
• Implement application-level logging to detect unexpected socket state changes or data loss
• Use kernel tracing tools (ftrace, eBPF) to monitor unix_vertex_dead() and MSG_PEEK interactions
• Deploy runtime kernel integrity monitoring to detect exploitation attempts

Monitoring Recommendations

• Enable kernel auditing for socket operations on systems running vulnerable kernel versions
• Implement application monitoring for Unix domain socket reliability metrics
• Configure alerting for unusual patterns in IPC communication failures
• Review system logs regularly for signs of socket-related anomalies

How to Mitigate CVE-2026-23394

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix commits
• Review applications using MSG_PEEK on Unix domain sockets for potential impact
• Consider temporarily disabling or limiting MSG_PEEK usage in critical applications if updates cannot be immediately applied
• Monitor affected systems for signs of exploitation or data corruption

Patch Information

The vulnerability has been resolved in the Linux kernel through commits that introduce a seqcount_t mechanism to properly synchronize MSG_PEEK operations with the garbage collector. The fix allows the GC to detect when MSG_PEEK has intervened and defer the SCC collection to the next GC run, avoiding the race condition without imposing performance penalties on MSG_PEEK operations.

Relevant kernel commits:

• Kernel Git Commit 37dd7ab332396eb8dd80b2dc7ea4b61abf767436
• Kernel Git Commit e5b31d988a41549037b8d8721a3c3cae893d8670

Workarounds

• Avoid using MSG_PEEK on Unix domain sockets in production environments until patched
• Implement application-level retry logic to handle potential data loss scenarios
• Consider using alternative IPC mechanisms temporarily for critical communication paths
• Apply kernel live patching solutions if available for your distribution

# Check current kernel version
uname -r

# Verify if patch commits are present in your kernel source
git log --oneline | grep -i "af_unix.*MSG_PEEK\|GC.*MSG_PEEK"

# Monitor for af_unix related kernel messages
dmesg | grep -i af_unix