Echo: linux: security update to 6.1.170-1

critical Tenable Self-Hosted Container Security Plugin ID 465673

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

- 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 (CVE-2026-23450)

Solution

Update the linux library and its related packages to version 6.1.170-1 or later.

Plugin Details

Severity: Critical

ID: 465673

Version: Revision 1.1

Type: Local

Family: Echo Local Security Checks

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Medium

Score: 6.9

Percentile: 96.96

CVSS v2

Risk Factor: Critical

Base Score: 10

Temporal Score: 7.4

Vector: CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C

CVSS Score Source: CVE-2026-23450

CVSS v3

Risk Factor: Critical

Base Score: 9.8

Temporal Score: 8.5

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Patch Publication Date: 5/1/2026

Vulnerability Publication Date: 4/3/2026

Reference Information

CVE: CVE-2026-23450

Detections

Analytics