CVE-2026-80985

What it actually does

The Linux kernel SMC-R v2 LLC parser does not bound DELETE_RKEY_V2 and ADD_LINK handling to the bytes that actually arrived. On links that share a v2 receive buffer, handlers read leftover contents of that buffer past the 44-byte LLC union and treat them as RDMA rkeys, which can delete legitimate registered rtokens or install up to 255 spurious ones. The result is corrupted link-group token state, failed subsequent RDMA operations, and high-impact disruption of SMC connections. Confidentiality is not affected; integrity of token tables is low and availability impact is high (network-reachable, no privileges or user interaction).

Why it matters to the business

Applications that depend on SMC-R for high-throughput sockets (Linux-to-Linux RoCE/InfiniBand or Linux-to-mainframe style connectivity) can see sudden connection loss, RDMA key invalidation, and service interruption. The record is about 20 days old, is not in CISA KEV, has no ransomware association, lists exploit maturity as none, and has a low, flat EPSS (~0.54%), so broad opportunistic exploitation is currently unlikely. Residual operational risk is concentrated on hosts that actually enable SMC and peer on SMC-Rv2 links.

How an attack unfolds

A remote peer on an SMC-R v2 link that uses a shared v2 receive buffer sends a short LLC DELETE_RKEY_V2 or ADD_LINK message whose declared rkey count exceeds the payload that was received. Kernel handlers then consume residual bytes from the shared receive buffer as rkeys and pass them to token delete or add-link install paths. A leftover value that collides with a registered rtoken removes it; ADD_LINK can likewise install tokens from residual data, leaving the link group with an inconsistent RDMA key table. Later RDMA operations fail and the SMC link is typically torn down or otherwise denied. No named threat actors or in-the-wild campaigns are associated with this issue, and no public exploit is indicated.

How to fix it

Install a Linux kernel that includes the net/smc fix which copies the SMC-Rv2 LLC tail into the queue entry, processes only the arrived message length, and treats inline rkeys as a union member rather than reading past the 44-byte structure. No distribution package versions were supplied with this record, so take the patched kernel from your vendor (changelog should cite this CVE or the SMC LLC v2 queue-entry copy) and reboot. Until then, disable SMC where it is not required (unload/blacklist the smc module, do not negotiate SMC on listeners) and limit which hosts may form SMC-R links. The earlier length bound for links without a shared v2 receive buffer is superseded by this fix.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the net/smc change that copies oversized SMC-Rv2 LLC tails into the LLC queue entry and no longer reads rkeys from leftover shared v2 RX buffer data. After reboot, verify the kernel release and that the smc module matches the patched build. Inventory exposure by checking whether SMC is enabled or loaded and whether AF_SMC / SMC-R links exist; hosts without SMC compiled or loaded are not affected.

Typical attack path

1. Find Linux peers that have SMC enabled and an SMC-R v2 link using a shared v2 receive buffer
2. Deliver an LLC DELETE_RKEY_V2 or ADD_LINK control message whose declared rkey count is larger than the bytes that arrived
3. Kernel LLC handlers read leftover shared-buffer bytes as rkeys instead of the arrived message tail
4. Registered RDMA tokens are deleted or spurious tokens are installed on the link group
5. Subsequent SMC/RDMA operations fail and the connection is disrupted, producing an availability outage

How to detect it

This is a kernel logic/state-corruption bug with no public exploit, so confirmed prior compromise is unlikely to leave unique malware artifacts. Hunt unpatched SMC hosts for clusters of unexplained SMC link-group teardowns, RDMA token delete/install failures, and application disconnects aligned with SMC-R traffic. Review kernel logs (dmesg, journald/kern.log) for smc/SMC LLC/rtoken errors around the event, netlink or smc-tools snapshots of link groups, and flow logs showing unexpected SMC/RDMA session resets from unusual peers. Absence of those symptoms does not prove non-exploitation; treat detection as supporting evidence and rely on patching for closure.

What your security team should do

• Prioritize kernel updates on systems that actually use SMC-R/RDMA; other Linux hosts can follow normal kernel cadence given low EPSS, no KEV listing, and no known exploit
• Inventory SMC usage (module loaded, AF_SMC sockets, SMC-R links) so patching and compensating controls target real exposure
• If a reboot window is delayed, disable or prevent SMC negotiation and restrict SMC-R peers
• Watch for unexplained SMC link teardowns or RDMA token failures on unpatched SMC hosts
• Re-evaluate only if exploit maturity or EPSS rises; current 30-day EPSS trend is flat