GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel net/smc: unlocked bitfield sharing corrupts SMC connection state flags

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

Impact

Three single-bit flags in struct smc_connection shared one byte, so every store was a read-modify-write of its neighbours, and they were written from contexts with no common lock - out_of_sync from the receive tasklet, killed from process context under lock_sock(), with the receive path taking only bh_lock_sock(). Concurrent stores can therefore lose or resurrect a flag, leaving connection teardown state inconsistent. The fix gives each flag its own byte, growing the struct by two bytes. This only matters on nodes that actually use SMC (AF_SMC / SMC-R over RoCE); that is uncommon outside IBM-influenced stacks, and a GPU fleet running ordinary TCP or native RDMA verbs is not exposed. The NVD 9.8 network-remote score is an automated placeholder and is not supported by the commit message, which describes a local data race, not remote code execution.

Who can reach it

Requires SMC sockets to be in use on the host. Exposure is to peers on an existing SMC connection and to local workloads that open AF_SMC sockets; there is no path for a tenant that cannot reach the SMC stack. If the smc module is not loaded, the node is not affected.

What to do

Pick up the fix in your stable kernel (three stable commits are linked) and reboot the node on the normal kernel-update cycle. If SMC is unused, blacklisting or not loading the smc module removes the exposure without a reboot, which is the cheaper answer for most fleets. Do not schedule an emergency drain on the strength of the NVD score.

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.