CVE-2026-23450

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
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*

History

24 Jul 2026, 21:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net/smc: corrige la desreferencia de NULL y el UAF en smc_tcp_syn_recv_sock() Syzkaller informó un pánico en smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() se llama en la ruta de recepción TCP (softirq) a través de icsk_af_ops -> syn_recv_sock en el clcsock (socket de escucha TCP). Lee sk_user_data para obtener el puntero smc_sock. Sin embargo, cuando el socket de escucha SMC se está cerrando concurrentemente, smc_close_active() establece clcsock -> sk_user_data en NULL bajo sk_callback_lock, y luego el propio smc_sock puede ser liberado a través de sock_put() en smc_release(). Esto lleva a dos problemas: 1) Desreferencia de puntero NULL: sk_user_data es NULL cuando se accede. 2) Uso después de liberación: sk_user_data se lee como no-NULL, pero el smc_sock es liberado antes de que se acceda a sus campos (por ejemplo, queued_smc_hs, ori_af_ops). La ventana de carrera se ve así (el fallo de syzkaller [1] se activa a través de la ruta de la cookie SYN: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), pero la ruta normal de tcp_check_req() tiene la misma carrera): CPU A (softirq) CPU B (contexto de proceso) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req -> rsk_listener sock_hold(sk) /* Sin bloqueo en el oyente */ 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 liberado! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL o colgante smc -> queued_smc_hs -> ¡fallo! Tenga en cuenta que el clcsock y el smc_sock son dos objetos independientes con recuentos de referencia separados. La pila TCP mantiene una referencia en el clcsock, lo que lo mantiene vivo, pero esto NO evita que el smc_sock sea liberado. Solucione esto utilizando RCU y refcount_inc_not_zero() para acceder de forma segura a smc_sock. Dado que smc_tcp_syn_recv_sock() se llama en la ruta del handshake de tres vías de TCP, tomar read_lock_bh en sk_callback_lock es demasiado pesado y no sobreviviría a un ataque de inundación SYN. Usar rcu_read_lock() es mucho más ligero. - Establezca SOCK_RCU_FREE en el socket de escucha SMC para que la liberación de smc_sock se posponga hasta después del período de gracia de RCU. Esto garantiza que la memoria sigue siendo válida cuando se accede dentro de rcu_read_lock(). - Use rcu_read_lock() para proteger la lectura de sk_user_data. - Use refcount_inc_not_zero(&smc -> sk.sk_refcnt) para fijar el smc_sock. Si el recuento de referencias ya ha llegado a cero (ruta de cierre completada), devuelve falso y salimos de forma segura. Nota: smc_hs_congested() tiene una lectura similar sin bloqueo de sk_user_data sin rcu_read_lock(), pero solo verifica si es NULL y accede al smc_hs_wq global, nunca desreferenciando ningún campo de smc_sock, por lo que no se ve afectado. El reproductor fue verificado con inyección de mdelay y smc_run, el problema ya no ocurre con este parche aplicado. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

14 Jul 2026, 13:18

Type Values Removed Values Added
References
  • () https://cert-portal.siemens.com/productcert/html/ssa-019113.html -
  • () https://cert-portal.siemens.com/productcert/html/ssa-082556.html -

21 May 2026, 00:32

Type Values Removed Values Added
First Time Linux linux Kernel
Linux
References () https://git.kernel.org/stable/c/1e4f873879e075bbd4eb1c644d6933303ac5eba4 - () https://git.kernel.org/stable/c/1e4f873879e075bbd4eb1c644d6933303ac5eba4 - Patch
References () https://git.kernel.org/stable/c/1fab5ece76fb42a761178dcd0ebcbf578377b0dd - () https://git.kernel.org/stable/c/1fab5ece76fb42a761178dcd0ebcbf578377b0dd - Patch
References () https://git.kernel.org/stable/c/6d5e4538364b9ceb1ac2941a4deb86650afb3538 - () https://git.kernel.org/stable/c/6d5e4538364b9ceb1ac2941a4deb86650afb3538 - Patch
References () https://git.kernel.org/stable/c/cadf3da46c15523fba90d80c9955f536ee3b4023 - () https://git.kernel.org/stable/c/cadf3da46c15523fba90d80c9955f536ee3b4023 - Patch
References () https://git.kernel.org/stable/c/f00fc26c8a06442b225a350fe000c0a11483e6a3 - () https://git.kernel.org/stable/c/f00fc26c8a06442b225a350fe000c0a11483e6a3 - Patch
References () https://git.kernel.org/stable/c/f315277856caeafcd996c2611afc085ca2d53275 - () https://git.kernel.org/stable/c/f315277856caeafcd996c2611afc085ca2d53275 - Patch
References () https://git.kernel.org/stable/c/fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2 - () https://git.kernel.org/stable/c/fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2 - Patch
CPE cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
CWE CWE-416

27 Apr 2026, 14:16

Type Values Removed Values Added
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 9.8

18 Apr 2026, 09:16

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/f315277856caeafcd996c2611afc085ca2d53275 -

03 Apr 2026, 16:16

Type Values Removed Values Added
New CVE

Information

Published : 2026-04-03 16:16

Updated : 2026-07-24 21:10


NVD link : CVE-2026-23450

Mitre link : CVE-2026-23450

CVE.ORG link : CVE-2026-23450


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-416

Use After Free