PT-2026-122009
CVE-2026-99032
·
Published
2026-10-23
·
Updated
2026-10-23
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾