CVE-2026-80982

What it actually does

A local race in the Linux kernel SMC (Shared Memory Communications) receive path produces a use-after-free. splice() can hand receive-memory-buffer pages to a pipe while a concurrent close runs smc_conn_free(), returning the RMB to the link-group pool (or freeing the descriptor on the is_reg_err path). smc_rx_pipe_buf_release() previously checked sk_state before taking the socket lock, so the state could change in that window and smc_rx_update_cons() then touched already-freed conn->rmb_desc / conn->lgr. The result is kernel memory corruption with High impact on confidentiality, integrity, and availability (CVSS 7.8, AV:L/PR:L), typically panics or, if the freed object is reclaimed and overwritten, arbitrary kernel read/write.

Why it matters to the business

A low-privilege local user or a compromised container/process can crash Linux hosts or escalate to kernel/root, taking down workloads and enabling full host takeover. Risk is concentrated on systems that actually use SMC (SMC-R/RoCE or SMC-D), not every Linux box. The issue is not in CISA KEV, has no known in-the-wild exploitation (exploit maturity None), and a very low, flat EPSS (~0.0017 over 30 days), so opportunistic mass exploitation is unlikely 20 days after publication. Multi-tenant, HPC, mainframe-adjacent, and shared-kernel environments should still treat this as a high-priority kernel patch because a successful exploit yields complete host compromise.

How an attack unfolds

An attacker who already has local unprivileged code execution on a host with SMC enabled sets up an SMC connection and splices received data into a pipe so RMB pages are held by pipe buffers with a socket reference. In parallel they force the SMC connection to close so smc_conn_free() releases the receive buffer and link-group state. If pipe-buffer release runs after that free but still believes the socket is live, it dereferences freed SMC structures. The attacker then tries to win the race repeatedly; a crash is the common outcome, while a won race against a reallocated object can be turned into kernel-memory corruption and privilege escalation. No named APT or ransomware campaign is associated with this CVE.

How to fix it

Apply the vendor/distribution kernel update that contains the upstream net/smc fix (take the socket lock first and test conn->freed instead of sk_state; smc_conn_free() sets that flag before releasing buffers). No specific package versions were supplied with this record, so use your distro’s advisory for the exact kernel package. If SMC is not required, mitigate by unloading or blacklisting the smc module and ensuring applications do not request SMC (e.g., avoid SMC-enabled TCP stacks / AF_SMC usage) until patched. Reboot into the patched kernel; this class of fix is not hot-patchable via configuration alone.

How to confirm the fix worked

Confirm the running kernel changelog or stable-commit list includes the smc_rx_pipe_buf_release() lock-ordering fix (lock socket first, test conn->freed). Check lsmod/kconfig for smc, and whether AF_SMC or SMC-fallback TCP is in use. After patching, reproduce only in a lab: splice receive data on an SMC socket while closing the connection and verify no KASAN/UAF or oops in smc_rx_pipe_buf_release/smc_rx_update_cons. On production, verify uname -r matches the patched package and that crash kernels/kdump no longer show that stack.

Typical attack path

1. Obtain local unprivileged execution on a Linux host where SMC is available (SMC-R or SMC-D).
2. Establish an SMC connection that allocates a receive memory buffer and related connection/link-group objects.
3. Splice SMC receive data into a pipe so RMB pages are referenced by pipe buffers.
4. Concurrently close or otherwise tear down the SMC connection so smc_conn_free() releases the RMB/link-group while pipe buffers still exist.
5. Trigger pipe-buffer release so smc_rx_pipe_buf_release() / smc_rx_update_cons() run against freed objects.
6. Repeat the race until a kernel oops occurs (denial of service) or corrupted kernel memory is leveraged for local privilege escalation.

How to detect it

There are no public in-the-wild exploits or named actors, so detection is crash- and telemetry-centric rather than C2-centric. Search kernel logs (dmesg, journalctl -k, /var/log/kern.log, kdump/vmcore, pstore) for oops/KASAN use-after-free reports whose stack includes smc_rx_pipe_buf_release, smc_rx_update_cons, smc_conn_free, smcr_buf_unuse, or smc_rx_splice. Correlate with local processes using splice() on SMC/AF_SMC sockets, sudden SMC connection teardown, and module smc loaded. Memory-corruption exploitation may leave no reliable network IOC; look for unexplained local privilege jumps, new root processes, or kernel-module loading shortly after an SMC-related oops. Absent those artifacts, prior exploitation is unlikely given exploit maturity None and flat near-zero EPSS.

• smc_rx_pipe_buf_release
• smc_rx_update_cons
• smc_rx_splice
• smc_conn_free
• smcr_buf_unuse
• KASAN: use-after-free
• net/smc
• Unable to handle kernel paging request

What your security team should do

• Patch and reboot Linux kernels to the distro build that includes the net/smc use-after-free fix; treat shared-kernel and multi-tenant hosts as highest priority despite low EPSS and non-KEV status.
• Inventory where SMC is loaded or used (smc module, AF_SMC, RoCE/SMC-D fabrics); disable or blacklist smc on hosts that do not need it.
• Hunt historical kernel oops/panic logs for SMC receive-path stacks from the last 20+ days; treat hits as possible local exploitation or instability, not proof of compromise by themselves.
• Keep local privilege boundaries tight (no untrusted code on SMC-enabled hosts) until the patched kernel is fully rolled out.
• Track distro advisories for exact package versions; this record does not list fixed versions.