CVE-2026-80985: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-80985 Overview

CVE-2026-80985 is an out-of-bounds read vulnerability in the Linux kernel's Shared Memory Communications over RDMA version 2 (SMC-Rv2) Link Layer Control (LLC) message handling. The functions smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() process the trailing portion of a v2 LLC message but bound their reads by the receive buffer size rather than the size of the message that actually arrived. A remote peer can send a 44-byte DELETE_RKEY_V2 declaring 255 rkeys, causing the kernel to read stale bytes from lgr->wr_rx_buf_v2 left by earlier messages and pass them to smc_rtoken_delete(). This can delete registered rtokens or install attacker-influenced rtokens through an ADD_LINK operation.

Critical Impact
A remote peer on an SMC-Rv2 link with a shared v2 receive buffer can trigger deletion of valid rtokens or installation of up to 255 attacker-influenced rtokens, causing integrity loss and denial of service on affected kernels.

Affected Products

Linux kernel versions containing the SMC-Rv2 LLC message handling code prior to the fix commits
Systems using net/smc with SMC-R v2 shared receive buffers
Distributions shipping vulnerable kernel builds pending backports

Discovery Timeline

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

Technical Details for CVE-2026-80985

Vulnerability Analysis

The vulnerability affects the SMC-R v2 LLC message parsing path in the Linux kernel's net/smc subsystem. LLC messages use a fixed 44-byte union smc_llc_msg structure, but v2 message variants carry additional data beyond that boundary. The parsing routines smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() reach into that tail through a cast and bound their access by the receive buffer size rather than the size of the arriving message.

When an SMC-R link uses a shared v2 receive buffer (lgr->wr_rx_buf_v2), stale contents from earlier messages remain in the buffer. A short 44-byte DELETE_RKEY_V2 message that declares 255 rkeys causes the kernel to read rkey[9..254] from whatever previously landed in the shared buffer. Each of those values is passed to smc_rtoken_delete(), and any match against a registered rtoken deletes it. An ADD_LINK message on the same link path installs up to 255 rtokens derived from the same stale bytes.

The fix copies the message tail into the queue entry so its length reflects the arriving message. Inline rkeys are declared as a union member instead of accessed through a pointer cast. The copy is bounded by the longest tail the two functions read, preventing the peer from choosing the entry size.

Root Cause

The root cause is improper bounds validation: parsing code trusted the receive buffer size instead of the announced message length. This is an out-of-bounds read that reaches into uninitialized or stale kernel memory, combined with a type confusion pattern where oversized message fields are accessed via pointer arithmetic beyond the declared union.

Attack Vector

The attack vector is network-based over an established SMC-R v2 link. No authentication or user interaction is required beyond the peer relationship. An attacker able to send crafted LLC control messages to a target participating in SMC-Rv2 can trigger the out-of-bounds read and influence rtoken state on the target.

No verified proof-of-concept code is available. Refer to the upstream commits for the technical fix details: Kernel Git Commit 0d6f80b, Kernel Git Commit 8d3c1ab, and Kernel Git Commit edf30d6.

Detection Methods for CVE-2026-80985

Indicators of Compromise

Unexpected deletion of registered RDMA rtokens on SMC-R v2 links, visible as dropped or reset RDMA sessions.
Kernel log entries from net/smc reporting DELETE_RKEY or ADD_LINK processing anomalies on shared v2 receive buffers.
SMC connection resets or link failures following receipt of oversized LLC v2 messages from a peer.

Detection Strategies

Inventory hosts with SMC-R v2 enabled (CONFIG_SMC) and identify those exposing RDMA endpoints to untrusted networks.
Correlate kernel version data against the fix commits to enumerate unpatched systems.
Monitor for abnormal rates of LLC control messages or unexpected rtoken state changes on SMC links.

Monitoring Recommendations

Collect dmesg and audit logs from hosts running SMC-R workloads and forward them to centralized logging.
Alert on unexpected RDMA session terminations or repeated smc_rtoken_delete events on production hosts.
Track kernel package versions across the fleet to confirm patch application after distribution updates ship.

How to Mitigate CVE-2026-80985

Immediate Actions Required

Apply the upstream kernel fixes referenced in the stable tree once vendor packages become available.
Restrict SMC-R v2 exposure to trusted network segments and known RDMA peers only.
Disable the SMC protocol on hosts that do not require it, using module blacklisting or kernel configuration.

Patch Information

Upstream fixes are available in the Linux kernel stable tree via Kernel Git Commit 0d6f80b, Kernel Git Commit 8d3c1ab, and Kernel Git Commit edf30d6. The patches copy the message tail into the queue entry using a bounded length and expose inline rkeys as a union member instead of a cast.

Workarounds

Blacklist the smc kernel module on systems that do not use Shared Memory Communications.
Limit SMC-R v2 peers to a defined allowlist enforced at the network layer.
Where feasible, prefer SMC-R v1 links or disable shared v2 receive buffers until patched builds are deployed.

bash

# Configuration example: disable the SMC kernel module
echo 'blacklist smc' | sudo tee /etc/modprobe.d/blacklist-smc.conf
sudo rmmod smc 2>/dev/null || true
sudo update-initramfs -u