CVE-2026-80986

What it actually does

The Linux kernel SMC-R v2 LLC path fails to bound peer rkey counts when parsing ADD_LINK messages. On RDMA devices with max_recv_sge == 1 there is no shared v2 receive buffer, so smc_llc_save_add_link_rkeys() treats a v2 extension that starts near the end of a 72-byte inline queue entry; reading num_rkeys (and following rkey data) is a slab-out-of-bounds access. This is a kernel memory-safety defect that can oops/panic the host and, depending on slab layout, corrupt adjacent objects.

Why it matters to the business

Linux systems that actually use Shared Memory Communications over RDMA (SMC-R/SMC-Rv2) can be crashed or destabilized during link setup, interrupting high-performance sockets used in RDMA/RoCE/InfiniBand and IBM Z-style environments. Hosts that never load SMC are not exposed. Severity is scored critical, but exploit maturity is none, EPSS is low and flat (~0.0065 over 30 days), the CVE is not in CISA KEV, and there is no ransomware association—treat as urgent for SMC/RDMA estates and routine kernel hygiene elsewhere. The issue was published about 20 days ago.

How an attack unfolds

A remote peer on a fabric where SMC-R v2 can be negotiated completes enough of an SMC connection for LLC ADD_LINK processing, then supplies an ADD_LINK v2 extension whose rkey count is unbounded or whose extension is interpreted past the inline 72-byte allocation. The receiver reads out of bounds in smc_llc_save_add_link_rkeys (commonly during smc_llc_cli_add_link / connect). Impact observed in the public report is a KASAN slab-out-of-bounds read and kernel BUG; follow-on memory corruption is theoretically possible but no public exploit, payload, or named threat-actor use is documented.

How to fix it

Install a vendor/distro kernel that includes the upstream net/smc fix bounding peer rkey counts in SMC-Rv2 LLC messages, then reboot into that kernel. Exact package versions were not supplied with this record—use your distributor’s advisory and changelog for net/smc or smc_llc_save_add_link_rkeys. If SMC is not required, blacklist the smc module and prevent AF_SMC usage as a compensating control, and restrict RDMA/SMC peering to trusted systems until patched.

How to confirm the fix worked

Confirm uname -r / package changelog lists the net/smc rkey-bounding fix. After reboot, smc should still load if needed, and adding an SMC-Rv2 link on a max_recv_sge==1 device must no longer produce KASAN slab-out-of-bounds in smc_llc_save_add_link_rkeys. If relying on disablement, verify the smc module is not loaded and no process holds AF_SMC sockets.

Typical attack path

1. Find Linux hosts with SMC/SMC-R enabled and RDMA NICs that can negotiate SMC-Rv2.
2. Obtain reachability on the RDMA or IP network used for SMC (typically a data-center fabric, not the open Internet).
3. Cause the target to process an SMC-R connect / ADD_LINK LLC exchange (as a peer or via an application that uses AF_SMC).
4. Trigger the un-bounded v2 rkey parse so the kernel reads past the inline LLC queue entry.
5. Induce a kernel oops/panic or unstable slab state, denying service on the host.

How to detect it

Review kernel rings, journald, kdump/vmcore, and panic logs on SMC-enabled hosts for out-of-bounds reports during connect or link-add. Search for smc_llc_save_add_link_rkeys, smc_llc_cli_add_link, __smc_connect, and KASAN slab-out-of-bounds. Correlate with AF_SMC connect activity, smc module load, and RDMA device use. No public exploit tooling, file drops, or named APT TTPs are associated; absence of these logs does not prove non-exploitation if KASAN was off and the host simply oopsed.

• smc_llc_save_add_link_rkeys
• BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rkeys
• smc_llc_cli_add_link
• __smc_connect
• smc_llc_enqueue
• KASAN: slab-out-of-bounds

What your security team should do

• Inventory Linux hosts with RDMA NICs and CONFIG_SMC/smc loaded; patch and reboot those first.
• Apply vendor kernel updates containing the SMC-Rv2 LLC rkey bound; do not wait for KEV given CVSS 9.8 on SMC estates.
• Where SMC is unused, blacklist smc and limit RDMA peering as a short-term control.
• Hunt kernel logs and crash dumps since publication for smc_llc_save_add_link_rkeys / KASAN hits.
• Track distro advisories for exact fixed kernel packages; EPSS is low so prioritize by actual SMC exposure rather than internet-wide emergency response.