Live › vulnerability › CVE-2026-99032
Go to dashboardA race in the Linux kernel's SMC socket code lets a getsockname() call touch a CLC socket that another worker has already released. The result is a use-after-free or NULL dereference in kernel memory, which can crash the machine or be turned into code execution by a local user.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only systems running a Linux kernel with the SMC (Shared Memory Communications) protocol in use are exposed, which is mainly hosts using SMC-R or SMC-D with multi-link-group setups; most ordinary servers do not load the module. The race needs a local process that can open SMC sockets and call getsockname() while link-group termination runs, so multi-tenant hosts and shared compute nodes are the main concern. Systems without the smc module can skip it.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds in your distribution's advisorylsmod | grep smc or grep -i smc /proc/net/protocols to see whether the SMC protocol is loadedsysctl net.smc.autocorking_size to confirm the SMC module is present (unknown if the sources do not say otherwise)modprobe -r smc_diag smc where it is not in use (unknown if the sources give a supported workaround)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: protect clcsock lifetime in smc_getname
smc_getname() dereferences smc->clcsock without holding clcsock_release_lock. Link-group termination can release the CLC socket through smc_close_active_abort() while the SMC socket is still open, for example after shutdown(SHUT_WR).
A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sock_release() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket.
KASAN reported the following with test-only timing instrumentation:
BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smc_getname+0x19e/0x1b0 do_getsockname+0xe5/0x170 __sys_getsockname+0x8c/0x100
Allocated by task 95: sock_alloc_inode+0x1e/0x280 sock_alloc+0x3d/0x240 __sock_create+0x7e/0x430 smc_create+0x121/0x240
Freed by task 0: kmem_cache_free+0xcc/0x340 rcu_core+0x50a/0x1850
Last potentially related work creation: evict+0x446/0x6c0 smc_clcsock_release+0xa8/0xd0 smc_close_active_abort+0x26a/0x3a0 __smc_lgr_terminate.part.0+0x137/0x2e0
Hold clcsock_release_lock across the pointer check and the getname() callback to serialize with smc_clcsock_release(). Return -EBADF if the CLC socket has already been released, preserving the existing peer state check and the callback's return value otherwise.
This page as .md · .json · in your agent: get_signal("CVE-2026-99032")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.