CVE-2026-23450
Received Received - Intake
Use-After-Free and NULL Dereference in Linux Kernel SMC TCP Socket

Publication date: 2026-04-03

Last updated on: 2026-04-27

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-03
Last Modified
2026-04-27
Generated
2026-05-07
AI Q&A
2026-04-04
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23450
EUVD
EUVD-2026-18700
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux_kernel linux_kernel *
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided CVE description does not include any information regarding the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's SMC (Shared Memory Communications) TCP receive path, specifically in the function smc_tcp_syn_recv_sock(). It involves a race condition where the smc_sock object can be freed while still being accessed, leading to two main issues: a NULL pointer dereference and a use-after-free (UAF).

The problem occurs because smc_tcp_syn_recv_sock() reads sk_user_data to get a pointer to smc_sock, but if the SMC listen socket is closed concurrently, sk_user_data can be set to NULL and the smc_sock freed before the function accesses its fields. This causes crashes or panics in the kernel.

The fix involves using Read-Copy-Update (RCU) mechanisms and safe reference counting to ensure that smc_sock is not freed while being accessed. This includes deferring freeing until after an RCU grace period and safely incrementing the reference count before use.


How can this vulnerability impact me? :

This vulnerability can cause kernel panics or crashes due to NULL pointer dereference or use-after-free errors in the Linux kernel's networking stack. Such crashes can lead to denial of service (DoS) conditions, making the affected system unstable or unavailable.

Because the issue occurs during the TCP handshake path, it could potentially be triggered by network traffic, including SYN flood attacks, exacerbating the impact by causing repeated kernel crashes.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability in the Linux kernel's smc_tcp_syn_recv_sock() function has been fixed by applying a patch that uses RCU and refcount_inc_not_zero() to safely access smc_sock.

  • Apply the patch that sets SOCK_RCU_FREE on the SMC listen socket to defer freeing smc_sock until after the RCU grace period.
  • Ensure the kernel uses rcu_read_lock() to protect reading sk_user_data in smc_tcp_syn_recv_sock().
  • Use refcount_inc_not_zero() to pin the smc_sock and safely handle the reference count.

These steps prevent NULL pointer dereference and use-after-free conditions by ensuring safe access to smc_sock during the TCP three-way handshake path.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart