ZeroHour

CVE-2026-80980

moderate

Race condition on shared-byte state flags in Linux kernel SMC connections

CVSS 3.1
9.8 critical
EPSS
Published
()
Modified
AI analysis

The Linux kernel's SMC (Shared Memory Communications, SMC-R/SMC-D) implementation packs three one-bit connection state flags — killed, freed, and out_of_sync — into a single byte of struct smc_connection, and they are written from different execution contexts without a common lock (out_of_sync from the receive tasklet in smc_cdc_msg_validate(), killed from process context under lock_sock() in smc_conn_kill()). Each store is a non-atomic read-modify-write of the shared byte, so concurrent updates can silently clobber each other — for example, a connection that was just killed or freed can lose that flag and continue to be used, with the potential for use-after-free and kernel memory corruption. Triggering the race requires being able to exchange SMC CDC traffic with a victim, so the attacker must effectively be a peer or on the path of an established SMC connection rather than an arbitrary internet host. The issue is scored 9.8 critical (network vector, no privileges, no user interaction), but real-world exposure is confined to systems actively using SMC, which is dominated by IBM Z/LinuxONE deployments with RDMA (RoCE/ISM) links; the vast majority of Linux hosts never use AF_SMC sockets. No public proof of concept is known, the flaw is not in CISA's KEV catalog, and no exploitation has been observed.

What to do: Apply the upstream kernel fix, which gives each flag its own byte in struct smc_connection (struct grows by two bytes), as soon as your distribution ships it; there is no configuration-only workaround because the race is inherent to the data layout. If SMC is not needed on a host, reduce exposure by preventing the smc module from loading (e.g., module blacklist) and confirming it is not loaded via 'lsmod | grep smc' or by checking for AF_SMC sockets. For SMC-enabled systems (mainly IBM Z with RoCE/ISM), restrict SMC peering to trusted networks and hosts, since exploitation requires the ability to send CDC messages on an SMC connection; monitor kernel logs for smc connection teardown anomalies or crashes that could indicate an attempted trigger.

Affected
Linux kernel
Estimated exposure
moderate≈ low tens of thousands of hosts worldwide actively terminating SMC connections (order of magnitude, clearly an estimate) — SMC is only used where applications explicitly opt into AF_SMC sockets over RDMA fabrics, which in practice is mainly IBM Z/LinuxONE enterprise installations and RoCE clusters; the installed base of such systems is small relative to…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: net/smc: stop killed, freed and out_of_sync sharing a byte The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock(). Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes.

Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.