CVE-2026-90065 net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure
An unprivileged local attacker can cause a kernel memory leak and denial of service by triggering SMC socket creation failures with a BPF program.
- Exploited in the wild
- Not known
- Login needed
- Any signed-in user
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-90065?
CVE-2026-90065 is a memory corruption vulnerability in Linux, published on 17 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official 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.
Which versions are affected by CVE-2026-90065?
How do I fix CVE-2026-90065?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-90065 being exploited?
There is no known exploitation of CVE-2026-90065 in the wild and no public exploit code.
Sources
Also known as BELL-CVE-2026-90065, DEBIAN-CVE-2026-90065, GHSA-6c8w-4wvx-63q5, UBUNTU-CVE-2026-90065.