CVE-2026-80986: Linux Kernel SMC-Rv2 Buffer Overflow

CVE-2026-80986 Overview

CVE-2026-80986 is an out-of-bounds read in the Linux kernel's Shared Memory Communications over RDMA v2 (SMC-Rv2) subsystem. The flaw lives in smc_llc_save_add_link_rkeys() within net/smc. When a link uses a device with max_recv_sge == 1, no shared v2 receive buffer exists. The function then reads the v2 extension from 44 bytes past the start of the inline message, which is only a 72-byte allocation. The read of ext->num_rkeys at offset 94 falls outside the allocated slab object, as confirmed by KASAN. The issue triggers on every SMC-Rv2 link addition, regardless of what the peer sends.

Critical Impact
A remote peer can trigger a slab out-of-bounds read on every SMC-Rv2 link addition, enabling denial of service and potential information disclosure on Linux hosts using SMC-R.

Affected Products

Linux kernel net/smc subsystem with SMC-Rv2 support
Systems using RDMA devices where max_recv_sge == 1
Distributions shipping the vulnerable SMC LLC handling code prior to the fix commits

Discovery Timeline

2026-09-11 - CVE-2026-80986 published to NVD
2026-09-13 - Last updated in NVD database

Technical Details for CVE-2026-80986

Vulnerability Analysis

The Shared Memory Communications over RDMA (SMC-R) protocol uses Link Layer Control (LLC) messages to negotiate remote keys (rkeys) between peers. In SMC-Rv2, an ADD_LINK message can carry an extension structure describing additional peer rkeys. The kernel handler smc_llc_save_add_link_rkeys() computes the extension pointer as llc_msg + SMC_WR_TX_SIZE, assuming that a shared v2 receive buffer holds the extension data.

On RDMA devices reporting max_recv_sge == 1, no such shared buffer is allocated. The queue entry is a 72-byte kmalloc slab object, with the extension arithmetic placing ext at offset 68 and ext->num_rkeys at offset 94. Reading offset 94 accesses memory beyond the object boundary, producing a KASAN slab-out-of-bounds report. Without bounds checks, the code also uses the unvalidated num_rkeys value to iterate over further out-of-bounds data.

Root Cause

The root cause is missing validation of the peer rkey count in SMC-Rv2 LLC messages combined with an incorrect assumption about buffer layout on links with max_recv_sge == 1. The handler dereferences memory past the end of the inline LLC message allocation and never bounds-checks num_rkeys before iterating.

Attack Vector

A remote peer participating in SMC-R link establishment can trigger the flaw by initiating an SMC-Rv2 link addition against a vulnerable host with an affected RDMA device. Exploitation requires no authentication beyond the ability to complete an SMC-R connection. Each link addition reads adjacent slab memory and processes attacker-influenced counts, enabling denial of service and creating a primitive for leaking neighboring slab contents.

No verified public exploit code is available. The vulnerability mechanism is described in the upstream commit messages referenced below.

Detection Methods for CVE-2026-80986

Indicators of Compromise

KASAN reports referencing smc_llc_save_add_link_rkeys with slab-out-of-bounds on read of size 2
Kernel call traces including smc_llc_cli_add_link, __smc_connect, and smc_wr_rx_tasklet_fn
Unexpected SMC-Rv2 link additions from untrusted peers on RDMA-capable interfaces

Detection Strategies

Enable KASAN on test kernels to surface out-of-bounds reads in net/smc code paths
Monitor kernel logs for BUG: KASAN entries and SMC subsystem oopses on production hosts
Inventory hosts running SMC-R and identify RDMA devices reporting max_recv_sge == 1

Monitoring Recommendations

Forward dmesg and journald kernel messages to a centralized logging platform for pattern matching on SMC and KASAN strings
Alert on repeated kernel warnings tied to smc_llc_* symbols, which indicate ongoing link-addition attempts
Track SMC-R connection metrics and correlate spikes with unexpected peer sources

How to Mitigate CVE-2026-80986

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 2d1e7c5, 486c699, and 5e5d9e6 as soon as vendor builds are available
Restrict SMC-R connectivity to trusted peers on isolated RDMA fabrics until patched kernels are deployed
Disable the SMC protocol on hosts that do not require it by blocking the smc module from loading

Patch Information

The fix bounds the peer rkey counts in SMC-Rv2 LLC messages and corrects the extension pointer handling for links without a shared v2 receive buffer. See the upstream commits: Kernel Git Commit 2d1e7c5, Kernel Git Commit 486c699, and Kernel Git Commit 5e5d9e6.

Workarounds

Blacklist the smc and smc_diag kernel modules on systems that do not use Shared Memory Communications
Enforce network-level filtering so only trusted RDMA peers can initiate SMC-R link additions
Where feasible, use RDMA devices whose max_recv_sge is greater than 1 to avoid the vulnerable code path pending patch deployment

bash

# Prevent the SMC modules from loading on hosts that do not need SMC-R
echo 'blacklist smc' | sudo tee /etc/modprobe.d/blacklist-smc.conf
echo 'blacklist smc_diag' | sudo tee -a /etc/modprobe.d/blacklist-smc.conf
sudo update-initramfs -u