GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SMC-R: duplicate LLC link messages from a peer leak one kmalloc-96 object each

CVE-2026-74719Kernel, userspace & hypervisorcurated

Impact

The CONFIRM_LINK / ADD_LINK_CONT branch of smc_llc_event_handler() stores an incoming qentry into the active LLC flow without the !flow->qentry guard its DELETE_LINK sibling has. A peer that sends a second such message while a flow is active overwrites the pointer and leaks the previous allocation - one kmalloc-96 object per spurious message, with no rate limit other than how fast the peer can send. Sustained, that is slab exhaustion on the host. SMC-R rides the RoCE/InfiniBand fabric that GPU nodes share across tenants, so the sender does not need to be on the node or in the tenant's namespace, only reachable on the fabric.

Who can reach it

Any peer that can establish an SMC-R link group with the node - fabric or network reachability where SMC is negotiated, no authentication beyond that. Nodes that do not use SMC have no exposure. The response direction is unaffected; only the request path leaks.

What to do

Update to a stable kernel with the added !flow->qentry guard and reboot. Where SMC is not actually used, blacklisting or not loading the smc module removes the exposure without a maintenance window and is the cheaper interim step on a fleet that cannot drain tonight.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-74719https://git.kernel.org/stable/c/06734dfeaeba886aab1bf147249195b888ac3e4dhttps://git.kernel.org/stable/c/10cb31b2b74cb664c6c95cf72364d7d5c483ab82https://git.kernel.org/stable/c/976245094925bab9bc39366b2e9ab44ffcde61d0

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.