CVE-2026-23450: Linux Kernel Use-After-Free Vulnerability

CVE-2026-23450 Overview

A critical race condition vulnerability has been discovered in the Linux kernel's SMC (Shared Memory Communications) subsystem within the smc_tcp_syn_recv_sock() function. This flaw, identified through Syzkaller fuzzing, results in both NULL pointer dereference and use-after-free conditions that can cause kernel panics and system crashes.

The vulnerability arises from improper synchronization between the TCP receive path (softirq context) and the SMC socket close path (process context). When an SMC listen socket is being closed concurrently with incoming TCP connections, the sk_user_data pointer can become NULL or point to freed memory, leading to kernel crashes when the softirq attempts to access the smc_sock structure.

Critical Impact

This vulnerability allows local attackers to trigger kernel panics through race condition exploitation, potentially causing denial of service on systems using SMC for network communications.

Affected Products

• Linux kernel with SMC (Shared Memory Communications) subsystem enabled
• Systems using SMC over RDMA or SMC-D for high-performance networking
• Enterprise Linux distributions with kernel SMC support

Discovery Timeline

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

Technical Details for CVE-2026-23450

Vulnerability Analysis

The vulnerability exists in the smc_tcp_syn_recv_sock() function, which is invoked during the TCP three-way handshake via the icsk_af_ops->syn_recv_sock callback on the clcsock (TCP listening socket). This function reads sk_user_data to obtain the smc_sock pointer, but a race condition exists between this read operation and the concurrent socket close operation.

The race window occurs because the clcsock and smc_sock are two independent objects with separate reference counts. While the TCP stack holds a reference on the clcsock (keeping it alive), this does NOT prevent the smc_sock from being freed. When smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock and then frees the smc_sock via sock_put() in smc_release(), the softirq path can encounter either a NULL pointer or a dangling pointer to freed memory.

Root Cause

The root cause is inadequate synchronization between the softirq context (TCP receive path) and the process context (SMC socket close path) when accessing shared state through sk_user_data. The original implementation lacked proper RCU protection and reference counting checks to ensure safe access to the smc_sock structure during concurrent operations.

The two specific failure modes are:

1. NULL pointer dereference: sk_user_data is NULL when accessed because smc_close_active() has already cleared it.
2. Use-after-free: sk_user_data is read as non-NULL, but the smc_sock has been freed before fields like queued_smc_hs or ori_af_ops are accessed.

Attack Vector

The attack leverages the timing window between socket operations. An attacker with local access can trigger this race by rapidly creating and closing SMC listen sockets while simultaneously generating incoming TCP connections. The race is particularly exploitable through the SYN cookie path (tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock()), though the normal tcp_check_req() path exhibits the same vulnerability.

The exploitation scenario follows this pattern:

• CPU A (softirq) processes tcp_v4_rcv() for a TCP_NEW_SYN_RECV state packet
• CPU B (process context) concurrently executes smc_close_active(), clearing sk_user_data and freeing the smc_sock
• CPU A's subsequent call to smc_tcp_syn_recv_sock() accesses invalid memory, causing a kernel crash

Detection Methods for CVE-2026-23450

Indicators of Compromise

• Kernel panic messages referencing smc_tcp_syn_recv_sock() in the call stack
• System crashes with NULL pointer dereference errors in the SMC subsystem
• Kernel oops reports mentioning use-after-free in SMC-related structures
• Syzkaller-style crash reports with queued_smc_hs field access failures

Detection Strategies

• Monitor kernel logs for panic events with stack traces containing smc_tcp_syn_recv_sock, tcp_check_req, or tcp_get_cookie_sock
• Implement kernel address sanitizer (KASAN) monitoring to detect use-after-free conditions in SMC code paths
• Deploy system monitoring for unexpected kernel crashes on hosts with SMC networking enabled
• Review dmesg output for BUG reports related to net/smc subsystem

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture detailed crash information for forensic analysis
• Configure alerting on kernel panic events, particularly on systems using SMC for RDMA or SMC-D communications
• Monitor system uptime metrics for unexpected reboots that may indicate exploitation attempts
• Implement Syzkaller or similar fuzzing in test environments to proactively detect similar race conditions

How to Mitigate CVE-2026-23450

Immediate Actions Required

• Apply the official kernel patches from the stable tree as soon as possible
• If patches cannot be immediately applied, consider disabling SMC subsystem if not critical to operations
• Monitor affected systems for kernel panic events indicating active exploitation
• Plan maintenance windows for kernel updates on production systems using SMC networking

Patch Information

The official fix implements RCU protection and reference counting to safely access the smc_sock structure. The key changes include:

• Setting SOCK_RCU_FREE on the SMC listen socket to defer freeing until after the RCU grace period
• Using rcu_read_lock() to protect reading sk_user_data
• Adding refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock, safely bailing out if the refcount has already reached zero

Patches are available from the kernel stable tree:

• Kernel Patch Commit 1e4f873
• Kernel Patch Commit 1fab5ec
• Kernel Patch Commit 6d5e453
• Kernel Patch Commit cadf3da
• Kernel Patch Commit f00fc26
• Kernel Patch Commit fd7579f0

Workarounds

• Disable SMC subsystem by blacklisting the smc kernel module if SMC networking is not required: echo "blacklist smc" >> /etc/modprobe.d/blacklist.conf
• Restrict local user access to systems where SMC is critical to reduce attack surface
• Implement network segmentation to limit exposure of systems requiring SMC functionality
• Consider using alternative high-performance networking solutions until patches are applied

# Temporary workaround: Disable SMC kernel module
echo "blacklist smc" | sudo tee /etc/modprobe.d/smc-blacklist.conf
sudo modprobe -r smc

# Verify SMC module is not loaded
lsmod | grep smc