Linux Kernel up to 7.0-rc4 smc_tcp_syn_recv_sock null pointer dereference

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
7.2$0-$5k0.00

Summaryinfo

A vulnerability, which was classified as critical, was found in Linux Kernel up to 7.0-rc4. This affects the function smc_tcp_syn_recv_sock. Such manipulation leads to null pointer dereference. This vulnerability is traded as CVE-2026-23450. There is no exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.0-rc4 and classified as critical. Affected by this issue is the function smc_tcp_syn_recv_sock. The manipulation with an unknown input leads to a null pointer dereference vulnerability. Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. Impacted is availability. CVE summarizes:

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

The advisory is available at git.kernel.org. This vulnerability is handled as CVE-2026-23450 since 01/13/2026. The exploitation is known to be difficult. Technical details are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 304974 (Linux Distros Unpatched Vulnerability : CVE-2026-23450), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.1.167, 6.6.130, 6.12.78, 6.18.20, 6.19.10 or 7.0-rc5 eliminates this vulnerability. Applying the patch 1e4f873879e075bbd4eb1c644d6933303ac5eba4/f00fc26c8a06442b225a350fe000c0a11483e6a3/cadf3da46c15523fba90d80c9955f536ee3b4023/fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2/1fab5ece76fb42a761178dcd0ebcbf578377b0dd/6d5e4538364b9ceb1ac2941a4deb86650afb3538 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (304974), EUVD (EUVD-2026-18700) and CERT Bund (WID-SEC-2026-0985). If you want to get best quality of vulnerability data, you may have to visit VulDB.

Affected

  • Google Container-Optimized OS
  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • SUSE openSUSE
  • Open Source Linux Kernel
  • RESF Rocky Linux
  • Microsoft Azure Linux

Productinfo

Type

Vendor

Name

Version

License

Website

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 7.3
VulDB Meta Temp Score: 7.2

VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔒
VulDB Reliability: 🔍

CNA Base Score: 9.8
CNA Vector (Linux): 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: Null pointer dereference
CWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physical: No
Local: No
Remote: Yes

Availability: 🔒
Status: Not defined

EPSS Score: 🔒
EPSS Percentile: 🔒

Price Prediction: 🔍
Current Price Estimation: 🔒

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Nessus ID: 304974
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2026-23450

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.1.167/6.6.130/6.12.78/6.18.20/6.19.10/7.0-rc5
Patch: 1e4f873879e075bbd4eb1c644d6933303ac5eba4/f00fc26c8a06442b225a350fe000c0a11483e6a3/cadf3da46c15523fba90d80c9955f536ee3b4023/fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2/1fab5ece76fb42a761178dcd0ebcbf578377b0dd/6d5e4538364b9ceb1ac2941a4deb86650afb3538

Timelineinfo

01/13/2026 CVE reserved
04/03/2026 +79 days Advisory disclosed
04/03/2026 +0 days VulDB entry created
06/25/2026 +83 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-23450 (🔒)
GCVE (CVE): GCVE-0-2026-23450
GCVE (VulDB): GCVE-100-355154
EUVD: 🔒
CERT Bund: WID-SEC-2026-0985 - Linux Kernel: Mehrere Schwachstellen

Entryinfo

Created: 04/03/2026 18:14
Updated: 06/25/2026 08:08
Changes: 04/03/2026 18:14 (58), 04/08/2026 07:16 (2), 04/19/2026 21:50 (1), 05/21/2026 03:04 (11), 06/25/2026 08:08 (7)
Complete: 🔍
Cache ID: 216::103

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion

No comments yet. Languages: en.

Please log in to comment.

◂ PreviousOverviewNext ▸

Want to know what is going to be exploited?

We predict KEV entries!