|
Vulnerabilities
< Back

CVE-2026-23450

Updated on 03 Apr 2026

Severity

6.4 Medium severity

Details

CVSS score
6.4
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE ID
Links
NISTCIRCLRHELUbuntu

Overview

About vulnerability

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

Details

Affected product:
Ubuntu 20.04 ELS
Affected packages:
linux-meta @ 5.4.0 (+1 more)

Fixes

KernelCare state

Live-patch status from KernelCare for each operating system.

Operating system Status Covered kernels
Debian 12 Released
35 kernels
  • 6.1.38-1
  • 6.1.38-2
  • 6.1.38-4
  • 6.1.52-1
  • 6.1.55-1
  • 6.1.64-1
  • 6.1.66-1
  • 6.1.69-1
  • 6.1.76-1
  • 6.1.27-1
  • 6.1.67-1
  • 6.1.85-1
  • 6.1.90-1
  • 6.1.94-1
  • 6.1.99-1
  • 6.1.106-3
  • 6.1.112-1
  • 6.1.115-1
  • 6.1.119-1
  • 6.1.123-1
  • 6.1.128-1
  • 6.1.124-1
  • 6.1.129-1
  • 6.1.133-1
  • 6.1.135-1
  • 6.1.137-1
  • 6.1.140-1
  • 6.1.139-1
  • 6.1.147-1
  • 6.1.148-1
  • 6.1.153-1
  • 6.1.158-1
  • 6.1.159-1
  • 6.1.162-1
  • 6.1.164-1
Debian 13 Planned —
Ubuntu 20.04 HWE AWS Released
5 kernels
  • 5.15.0-1080.87~20.04.1
  • 5.15.0-1081.88~20.04.1
  • 5.15.0-1082.89~20.04.1
  • 5.15.0-1083.90~20.04.1
  • 5.15.0-1084.91~20.04.1
Ubuntu 20.04 HWE Azure Released
4 kernels
  • 5.15.0-1086.95~20.04.1
  • 5.15.0-1087.96~20.04.1
  • 5.15.0-1088.97~20.04.1
  • 5.15.0-1089.98~20.04.1
Ubuntu 22.04 Released
27 kernels
  • 5.15.0-135.146
  • 5.15.0-136.147
  • 5.15.0-138.148
  • 5.15.0-139.149
  • 5.15.0-140.150
  • 5.15.0-141.151
  • 5.15.0-142.152
  • 5.15.0-143.153
  • 5.15.0-144.157
  • 5.15.0-151.161
  • 5.15.0-152.162
  • 5.15.0-153.163
  • 5.15.0-156.166
  • 5.15.0-157.167
  • 5.15.0-160.170
  • 5.15.0-161.171
  • 5.15.0-163.173
  • 5.15.0-164.174
  • 5.15.0-168.178
  • 5.15.0-170.180
  • 5.15.0-171.181
  • 5.15.0-173.183
  • 5.15.0-174.184
  • 5.15.0-176.186
  • 5.15.0-177.187
  • 5.15.0-179.189
  • 5.15.0-181.191
Ubuntu 22.04 AWS Released
27 kernels
  • 5.15.0-1080.87
  • 5.15.0-1081.88
  • 5.15.0-1082.89
  • 5.15.0-1083.90
  • 5.15.0-1084.91
  • 5.15.0-1085.92
  • 5.15.0-1086.93
  • 5.15.0-1087.94
  • 5.15.0-1088.95
  • 5.15.0-1089.96
  • 5.15.0-1090.97
  • 5.15.0-1091.98
  • 5.15.0-1092.99
  • 5.15.0-1093.100
  • 5.15.0-1095.102
  • 5.15.0-1096.103
  • 5.15.0-1097.104
  • 5.15.0-1098.105
  • 5.15.0-1099.106
  • 5.15.0-1100.107
  • 5.15.0-1101.108
  • 5.15.0-1103.110
  • 5.15.0-1104.111
  • 5.15.0-1105.112
  • 5.15.0-1106.113
  • 5.15.0-1108.115
  • 5.15.0-1109.116
Ubuntu 22.04 Azure Released
21 kernels
  • 5.15.0-1084.93
  • 5.15.0-1086.95
  • 5.15.0-1087.96
  • 5.15.0-1088.97
  • 5.15.0-1089.98
  • 5.15.0-1090.99
  • 5.15.0-1091.100
  • 5.15.0-1092.101
  • 5.15.0-1094.103
  • 5.15.0-1095.104
  • 5.15.0-1096.105
  • 5.15.0-1097.106
  • 5.15.0-1098.107
  • 5.15.0-1101.110
  • 5.15.0-1102.111
  • 5.15.0-1099.108
  • 5.15.0-1103.112
  • 5.15.0-1109.118
  • 5.15.0-1110.119
  • 5.15.0-1111.120
  • 5.15.0-1114.123
Ubuntu 24.04 Planned —
Ubuntu 24.04 AWS Planned —