Cloudanix VulnDB

CVE-2026-80983

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux bug in a specialized high-speed networking feature can leak memory and stop network resources from being cleaned up when connections fail over.

Exploitation
Other
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A socket reference-count leak in the Linux kernel SMC (Shared Memory Communications) path: smc_switch_conns() takes sock_hold() then drops lgr->conns_lock so it can prefetch a CDC slot, but the early failure path from smc_cdc_get_free_slot() returns without the matching sock_put(). The smc_sock is never destroyed, send/receive buffers stay allocated, and a user socket’s hold on the network namespace is never released, so the netns cannot be torn down. The miss is hit when the target link goes down or the connection is killed during the same failover this function implements.

Why it matters to the business

Systems that actually use SMC (typically RDMA/RoCE/ISM high-performance fabrics) can slowly leak kernel memory and get stuck network namespaces after link failures, causing cleanup failures, capacity loss, and eventual denial of service rather than remote code execution. The issue is not in CISA KEV, has no ransomware association, exploit maturity is none, and EPSS is ~0.0017 and flat over 30 days, so urgency is low except on fleets that load SMC. Hosts that never enable CONFIG_SMC or load the smc module are not affected.

How an attack unfolds

This is a condition-triggered resource leak, not a remote takeover. An attacker who can cause SMC connections to run through link-group failover—and who can make the target link unavailable or the connection die while a CDC slot is being prefetched—hits the unbalanced sock_hold. Repeating those failover conditions accumulates immortal sockets, buffers, and netns references until memory or namespace teardown fails. Triggering requires the SMC stack and typically specialized interconnect hardware; there is no public exploit, named threat actor, or KEV/ransomware use.

How to fix it

Install a Linux kernel that contains the net/smc fix which restructures smc_switch_conns() so one sock_put() covers both success and the smc_cdc_get_free_slot() failure path. Use your distro or vendor kernel advisory for the exact package version; no per-package fixed versions were supplied with this record. If SMC is not required, do not load smc/smc_diag (blacklist the modules) and leave CONFIG_SMC unused. There is no safe sysctl that closes the leak while SMC failover remains in use.

How to confirm the fix worked

Confirm the running kernel includes the patched smc_switch_conns() (single sock_put covering both outcomes) via distro changelog, stable-commit mapping, or source. Check whether CONFIG_SMC is set and whether smc/smc_diag are loaded. After patching, exercise SMC link failover or a CDC slot allocation failure and verify socket/netns reference counts return to baseline and namespaces can be destroyed. Unpatched kernels that load SMC remain exposed.

Typical attack path

  1. Find Linux hosts that load the SMC stack and use RDMA, RoCE, or ISM links.
  2. Cause SMC connections to enter link-group failover (the path that calls smc_switch_conns()).
  3. Arrange for CDC slot allocation to fail during the switch (target link down or connection already killed).
  4. Repeat until leaked socket and namespace references exhaust kernel memory or block netns destruction.
  5. Result is availability impact (DoS / stuck namespaces), not code execution.

How to detect it

This is a silent leak, not a unique oops. Hunt around SMC link-down or failover for unexplained slab/socket growth and network namespaces that will not destroy. Review kernel logs for SMC link, failover, and CDC/slot allocation failures; inspect sock and netns reference-count growth; and confirm whether smc modules and RDMA/ISM devices are present. There are no public exploit artifacts, ransomware IOCs, or named-actor TTPs for this issue.

What your security team should do

  • Inventory hosts with CONFIG_SMC or loaded smc/smc_diag; deprioritize systems that never use SMC.
  • Patch the kernel to a release that includes the net/smc sock_put leak fix.
  • If SMC is unused, blacklist smc and smc_diag as defense in depth.
  • On RDMA/HPC fleets, watch for unreclaimable netns and growing SMC socket/buffer usage after link events.
  • Treat as low urgency (not KEV, no known exploit, EPSS ~0.0017 and unchanged) but do not skip SMC-enabled hosts.

The record

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.

Affected packages

Ecosystem Package Introduced Fixed