GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel net/smc: out-of-bounds read parsing the v2 extension on every SMC-Rv2 link addition

UnscoredCVE-2026-80986Kernel, userspace & hypervisorcurated

Impact

On an RDMA device that reports max_recv_sge == 1 there is no shared v2 receive buffer, so smc_llc_save_add_link_rkeys() takes the v2 extension at 44 bytes past the inline message inside a 72-byte allocation - the num_rkeys field at offset 94 is already past the end of the object. KASAN shows the slab-out-of-bounds read firing on every SMC-Rv2 link addition regardless of what the peer sends, and the rkey count read out of adjacent heap then drives how many rtokens are installed. The practical result is heap data read into RDMA rkey state on link setup, with the attendant risk of a panic under KASAN or hardened allocators. This is a distinct code path from CVE-2026-80985 and has its own fix; a node can be exposed to one and not the other depending on the HCA.

Who can reach it

Triggered locally by any SMC-Rv2 link addition on a host whose RDMA device has max_recv_sge == 1 - no peer action is required beyond establishing the link, and no authentication to the host is involved.

What to do

Update to the stable kernel carrying commit 2d1e7c5aaa33 (or your branch's backport) and reboot the node. If SMC is not used on the fleet, unloading or blacklisting the smc module avoids the path without a maintenance window.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.