AZL-110891: CVE-2026-99032 affecting package kernel 6.6.157.1-1

Q: What conditions are needed to trigger this issue?

The affected path involves an SMC socket whose associated CLC socket is released asynchronously during link-group termination while the SMC socket remains open. The description gives shutdown(SHUT_WR) followed by getsockname() as an example timing that can expose the race.

Q: What could happen when the race occurs?

A getsockname() caller may access the CLC socket after it has been released, causing a use-after-free. If the CLC socket pointer is cleared before it is loaded, the result can instead be a NULL-pointer dereference.

Q: Does keeping the SMC socket open prevent the problem?

No. A file reference keeps the SMC socket alive, but it does not prevent asynchronous release of the associated CLC socket.

Published Oct 23, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

net/smc: protect clcsock lifetime in smcgetname

smcgetname() dereferences smc->clcsock without holding clcsockreleaselock. Link-group termination can release the CLC socket through smccloseactiveabort() while the SMC socket is still open, for example after shutdown(SHUTWR).

A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sockrelease() 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 smcgetname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smcgetname+0x19e/0x1b0 dogetsockname+0xe5/0x170 sysgetsockname+0x8c/0x100

Allocated by task 95: sockallocinode+0x1e/0x280 sockalloc+0x3d/0x240 sockcreate+0x7e/0x430 smccreate+0x121/0x240

Freed by task 0: kmemcachefree+0xcc/0x340 rcucore+0x50a/0x1850

Last potentially related work creation: evict+0x446/0x6c0 smcclcsockrelease+0xa8/0xd0 smccloseactiveabort+0x26a/0x3a0 smclgrterminate.part.0+0x137/0x2e0

Hold clcsockreleaselock across the pointer check and the getname() callback to serialize with smcclcsockrelease(). Return -EBADF if the CLC socket has already been released, preserving the existing peer state check and the callback's return value otherwise.

Affected Software

1 affected component

azure-linux/kernel<=6.6.157.1-1

Event History

Oct 23, 2026

Advisory Published

via OSV·01:17 PM

Data Sourced

via OSV·01:17 PM

DescriptionAffected Software

Child vulnerabilities

Contains the following vulnerabilities.

CVE-2026-99032

Frequently Asked Questions

What conditions are needed to trigger this issue?

The affected path involves an SMC socket whose associated CLC socket is released asynchronously during link-group termination while the SMC socket remains open. The description gives shutdown(SHUT_WR) followed by getsockname() as an example timing that can expose the race.

What could happen when the race occurs?

A getsockname() caller may access the CLC socket after it has been released, causing a use-after-free. If the CLC socket pointer is cleared before it is loaded, the result can instead be a NULL-pointer dereference.

Does keeping the SMC socket open prevent the problem?

No. A file reference keeps the SMC socket alive, but it does not prevent asynchronous release of the associated CLC socket.

AZL-110891: CVE-2026-99032 affecting package kernel 6.6.157.1-1

Affected Software

Event History

Child vulnerabilities

Frequently Asked Questions

What conditions are needed to trigger this issue?

What could happen when the race occurs?

Does keeping the SMC socket open prevent the problem?

Company

Resources

Contact

Frequently Asked Questions

What conditions are needed to trigger this issue?

What could happen when the race occurs?

Does keeping the SMC socket open prevent the problem?