CVE-2026-80981

What it actually does

A use-after-free in the Linux kernel Shared Memory Communications (SMC) LLC server add-link path. smc_llc_srv_add_link() retains a pointer into an LLC queue entry, frees that entry with smc_llc_flow_qentry_del(), then later reads the dangling pointer in smc_llc_save_add_link_rkeys() when the link has no shared v2 receive buffer. The result is a kernel slab UAF that can panic the host or corrupt kernel heap, with confidentiality, integrity, and availability all theoretically at risk.

Why it matters to the business

Hosts that use SMC (RDMA/RoCE or SMC-R/SMC-D low-latency networking) can suffer kernel panics, lost connections, and unexpected downtime of high-performance fabric paths. The issue is rated critical (CVSS 9.8) because a network-reachable UAF in kernel networking can, in principle, fully compromise a host. Practical urgency is tempered by low current exploitation likelihood (EPSS about 0.63% with a flat 30-day trend, not listed in CISA KEV, no known ransomware use, exploit maturity none, published about 20 days ago), but organizations that enable SMC should still patch promptly because a kernel networking UAF is an availability and host-integrity event, not just an application bug.

How an attack unfolds

An unauthenticated network peer that can complete or induce an SMC handshake against a listening host causes the kernel SMC workqueue (smc_hs_wq / smc_listen_work) to process an LLC add-link message. The server path saves a pointer into the queued LLC message, deletes and frees the queue entry, then—on links without a shared v2 RX buffer—reuses that freed pointer while copying rkeys. Heap reuse of the freed object can turn the UAF into a crash or further kernel-memory corruption. No named threat actors, KEV campaigns, or ransomware families are associated with this issue at publication time.

How to fix it

Apply the upstream Linux kernel fix for net/smc that stops using the LLC qentry pointer after smc_llc_flow_qentry_del() (copy needed fields first or always use the shared v2 RX buffer path). Upgrade to a vendor or distro kernel that includes that net/smc patch; no specific package versions were supplied with this record, so map CVE-2026-80981 via your kernel changelog, stable-tree commit, or vendor advisory. If SMC is not required, mitigate by not loading the smc module, disabling SMC offload/handshake on sockets, and restricting RDMA/RoCE exposure until patched kernels are deployed.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory lists this CVE or the net/smc LLC qentry UAF fix. On patched kernels, smc_llc_srv_add_link() must not pass a pointer into a freed qentry into smc_llc_save_add_link_rkeys(). Inventory hosts with the smc module loaded, RDMA/RoCE devices present, or SMC-enabled listeners. After upgrade, verify uname/kernel package version, that smc still loads only where intended, and that no KASAN/oops traces reference smc_llc_save_add_link_rkeys or smc_llc_srv_add_link during SMC bring-up.

Typical attack path

1. Identify a Linux host with the SMC subsystem loaded and listening for SMC connections.
2. Reach the host over the network and participate in the SMC connection/LLC add-link flow as a peer.
3. Cause smc_llc_srv_add_link() to enqueue, then free, the LLC queue entry while a pointer into that entry remains live.
4. Trigger the post-free read in smc_llc_save_add_link_rkeys() on a link that does not use a shared v2 receive buffer.
5. Convert the resulting kernel slab use-after-free into a denial of service (oops/panic) or attempt further heap corruption for privilege impact.

How to detect it

Hunt historical kernel logs, kdump/vmcore, and KASAN/KFENCE reports for use-after-free in the SMC LLC add-link path. Primary artifacts are oops or KASAN reports in smc_llc_save_add_link_rkeys and smc_llc_srv_add_link, often on workqueue smc_hs_wq running smc_listen_work (kworker). Also review dmesg around SMC listen/handshake and any slab-use-after-free against the LLC qentry allocation site (smc_llc_enqueue / smc_wr_rx_tasklet_fn). Absence of these traces does not prove non-exploitation on non-debug kernels; a panic in SMC listen work during add-link is still suspicious. There are no public threat-actor TTPs or ransomware IOCs tied to this CVE.

• BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys
• smc_llc_save_add_link_rkeys
• smc_llc_srv_add_link
• Workqueue: smc_hs_wq smc_listen_work
• smc_listen_work
• smc_llc_flow_qentry_del
• smc_llc_enqueue
• smc_wr_rx_tasklet_fn

What your security team should do

• Patch Linux kernels that include net/smc as a high priority on any host where SMC or RDMA is enabled, despite low EPSS and no KEV listing.
• Inventory and reduce SMC/RDMA attack surface: unload smc where unused, restrict who can initiate SMC, and segment RoCE/RDMA fabrics.
• Watch kernel logs and panic dumps for SMC LLC UAF/oops signatures until fleets are confirmed patched.
• Track distro stable kernels and vendor advisories for the exact package that contains the net/smc fix, then validate rollout.
• Do not wait for in-the-wild exploitation; treat kernel networking UAFs as crash and potential privilege-escalation risk on exposed listeners.