Linux kernel SMC-R: use-after-free of the LLC queue entry when adding a second RDMA link

CVSS 9.8CVE-2026-80981Kernel, userspace & hypervisorcurated

Impact

On a server accepting SMC-R connections, smc_llc_srv_add_link() keeps a pointer into an LLC queue entry that has already been kfree()d, then reads the ADD_LINK rkey data out of it. On a link without a shared v2 receive buffer (max_recv_sge == 1) the freed slab object is read on every second-link setup, which a peer on the RoCE/InfiniBand fabric drives during normal link-group formation. The reachable outcome is freed-memory reads in a softirq/workqueue context, so the practical risk is kernel memory disclosure into LLC state or a crash of the SMC listener. This only matters on fleets that actually enable SMC-R over RoCE for east-west traffic; the fabric is shared across tenants, so the peer that drives the path need not be trusted.

Who can reach it

A remote SMC-R peer that can complete a link group with the host over RDMA, i.e. anyone reachable on the storage or east-west fabric. No local access and no authentication beyond being an accepted SMC peer; the module must be loaded and SMC in use.

What to do

Take the stable-kernel fix from one of the linked kernel.org commits and reboot the node; there is no hot patch and no runtime toggle short of preventing SMC-R link groups from forming. Operators who do not use SMC can confirm the smc module is not loaded and treat this as not applicable. Fixed versions are given by the stable commits only - the record names no release number.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80981 https://git.kernel.org/stable/c/a42a459ef0e54cb0c4b3e43e21cb0e658e664f64 https://git.kernel.org/stable/c/adef84cc85d449ac28d2b4b4c49cf19619c56e27 https://git.kernel.org/stable/c/c52a998a223e7e84333306996edec096178d1e95

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.