CVE-2026-80979

What it actually does

A use-after-free race in the Linux kernel Shared Memory Communications (SMC) stack lets a receive tasklet dereference a freed send buffer during connection teardown. smc_conn_free() only unregisters via smc_ism_unset_conn() while the link group is still on the device list and never sets conn->killed. smc_lgr_terminate_sched() unlinks the group immediately and defers connection kill to a work item, so a connection freed in that window keeps its smcd->conn[] slot with both smcd_handle_irq() gates open. The device can then re-arm the RX tasklet after tasklet_kill() returns; on the DMB-nocopy path the ghost send buffer is already freed, so the tasklet uses a dangling pointer. The result is kernel memory corruption with high confidentiality, integrity, and availability impact from a local low-privilege context (CVSS 7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Why it matters to the business

Hosts that use Linux SMC (high-performance shared-memory networking over ISM or RoCE, typical on IBM Z and some HPC/enterprise Linux deployments) can suffer kernel panics and unplanned outages, or local privilege escalation to full kernel/root control. The flaw is not in CISA KEV, has no reported ransomware or named-actor use, exploit maturity is None, and EPSS is very low (~0.00175, flat over 30 days), so opportunistic mass exploitation risk is currently limited. Recency (published about 20 days ago) and the high local impact still justify prompt kernel updates on any system that loads the SMC stack.

How an attack unfolds

A local low-privilege attacker on a system where SMC is in use arranges concurrent link-group termination and connection free. Because unregister is skipped once the link group is unlinked and conn->killed is never set, the connection remains visible to device IRQ handling. After the RX tasklet is believed drained, hardware or the ISM device re-arms it; the tasklet then follows the already-freed DMB-nocopy send buffer. That kernel use-after-free can crash the host or, with typical kernel-heap shaping, be turned into arbitrary kernel read/write and privilege escalation. No public exploit, KEV listing, or named threat-actor campaign is reported.

How to fix it

Apply the vendor/distribution kernel update that unregisters the SMC connection unconditionally, drains the RX tasklet before detach at both teardown sites (mirroring rmb_desc / smc_buf_unuse()), and clears conn->sndbuf_desc before the send buffer is freed. No specific upstream version numbers were supplied with this record; use your distro’s security advisory for the exact kernel package. If SMC is not required, blacklist or unload the net/smc modules (e.g. smc, smc_diag) and avoid SMC-R/SMC-D workloads until patched. Do not rely on tasklet_kill() alone as a mitigation.

How to confirm the fix worked

Confirm the running kernel includes the net/smc teardown fix (unregister-before-drain and sndbuf_desc clear) via distro changelog, uname -r against the advisory, or inspection of smc_conn_free / smc_lgr_terminate_sched in the installed vmlinux/module. Check whether SMC is loaded (lsmod | grep smc, presence of AF_SMC sockets, ISM/RoCE SMC use). After patching, reboot into the new kernel and re-verify module/build IDs. There is no safe production PoC; do not attempt to reproduce the race on production hosts.

Typical attack path

1. Obtain local unprivileged code execution or a local account on a Linux host with SMC (ISM/RoCE) in use
2. Cause SMC connections and link groups to be created and then torn down so smc_lgr_terminate_sched() unlinks the group while smc_conn_free() still runs
3. Win the teardown race so the connection stays in smcd->conn[] with IRQ gates open and conn->killed unset
4. Have the device re-arm the RX tasklet after tasklet_kill() returns, so the tasklet touches the freed DMB-nocopy send buffer
5. Convert the resulting kernel UAF into a panic (availability) or kernel memory read/write and privilege escalation

How to detect it

This is a local kernel race with no network exploit signature and no public exploit, so detection of prior abuse is forensic rather than IDS-based. Review kernel logs (dmesg, journalctl -k, /var/log/kern.log, crash dumps, pstore, kdump vmcores) for oops/panic/use-after-free reports whose stacks mention SMC RX handling or connection free. Look for crashes after SMC link-group termination or device IRQ storms on ISM/SMC-D paths. Correlate with local process activity that used AF_SMC around the crash. Absence of these artifacts does not prove the race was never hit. Named threat-actor or ransomware telemetry is not associated with this CVE.

• smcd_handle_irq
• smc_conn_free
• smc_lgr_terminate_sched
• smc_ism_unset_conn
• smc_buf_unuse
• sndbuf_desc
• net/smc
• Unable to handle kernel paging request
• use-after-free
• tasklet
• AF_SMC
• smc_ism
• smcd

What your security team should do

• Inventory Linux hosts that load net/smc or run SMC-D/SMC-R (ISM/RoCE) and prioritize kernel updates there
• Patch and reboot to a kernel that unregisters SMC connections before draining the RX tasklet and that nulls sndbuf_desc before free
• If SMC is unused, disable/blacklist smc modules as a compensating control until patched
• Treat this as a local LPE/DoS risk (CVSS 7.8) but not as mass internet exposure; EPSS is low and it is not KEV
• Hunt historical kernel oops/panic stacks involving smc/smcd around the publication window; no named actors or ransomware use is known
• Subscribe to distro kernel advisories for the exact package that contains this fix