CVE-2026-80985

A logic flaw in the Linux kernel's SMC-Rv2 link-layer control (LLC) message handling lets a malicious SMC peer make the kernel read stale bytes from the shared v2 receive buffer as if they were rkey data. The functions smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() bounded their reads by the size of the buffer rather than by the length of the message that actually arrived, so a short 44-byte DELETE_RKEY_V2 message declaring 255 rkeys would process leftover bytes from earlier messages — deleting a legitimately registered rtoken or installing up to 255 bogus rtokens from an ADD_LINK. The result is primarily a denial of service on SMC-R connections (CVSS 3.1: 8.2, A:H, I:L) caused by an unauthenticated network peer corrupting connection state. Only Linux systems actually speaking SMC-Rv2 over RDMA-capable links — typically IBM Z/LinuxONE estates using RoCE — are affected. No public proof of concept is known and the issue is not in CISA's KEV.

What to do: Update to a kernel that includes the fix, which copies the message tail into the queue entry so processing is bounded by the message that actually arrived. If SMC is not needed on a host, blacklist or unload the smc kernel module to remove the attack surface entirely. On SMC-R-enabled systems, restrict peers to trusted RoCE networks and watch for unexplained rtoken deletions or unexpected ADD_LINK behavior.