CVE-2026-80983

net/smc: fix socket refcount leak in smc_switch_conns()

N/A
Published: September 11, 2026 at 07:42 PM UTC
Updated: October 30, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

0d9ddf515cde793841f738490037560fd6559c635.10.905.14.145.1595f7f3e7dc6bd2e735cb5de11734ea2222b1e05a99f19566b1c4d3dc4d934ee2ef43faadebb56d70
Vendor states this is fixed in 09d7a9e162ee1a269878c126aee3d7eff43e4130 (fixed)
Vendor states this is fixed in 719296c4aa8213d4ac8002e77d5956d436bc98d0 (fixed)
Vendor states this is fixed in 84dea0585f6b538ae895a8b1d025f4897737f3b1 (fixed)
Vendor states this is fixed in a3378466704e0bbe93aef9769552dca7673a7eb6 (fixed)
Vendor states this is fixed in d89dc1bd8845c669a700eee58c64ebd3cc1b6d2d (fixed)
Vendor states this is fixed in d9a879ac25958bdaecb669ce70e58f8e2ff170de (fixed)
Vendor states this is fixed in e20227019d9da73f8fdf16f0951c2e188c84933f (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.15 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.109 (unaffected)
Vendor states this is fixed in 6.18.50 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.4 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card