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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:04.407Z",
  "pubdate": "2026-09-11T20:19:04.407Z",
  "executiveSummary": "This vulnerability involves a data race condition within the Linux kernel's Shared Memory Communications (SMC) protocol implementation.\nThe root cause is the use of bitfields to manage connection state flags (killed, freed, and out_of_sync) within the struct smc_connection structure.\nBecause these bitfields share a single byte and are accessed concurrently without consistent synchronization, a read-modify-write (RMW) race condition is introduced.\nThe vulnerability allows for potential state corruption, as updates to one flag can inadvertently overwrite the state of another flag.\nThe issue affects the network stack of the Linux kernel, specifically within the SMC implementation.\nThe risk includes unpredictable socket behavior, potential memory corruption, or logic errors in connection management.\nExploitation requires an attacker to trigger concurrent socket operations, typically involving the receive tasklet and process-context socket functions.\nSuccessful exploitation could lead to denial-of-service conditions or inconsistent connection states.",
  "technicalDetails": "The vulnerability originates from the architectural design of struct smc_connection in the Linux kernel's net/smc component. Specifically, the flags 'killed', 'freed', and 'out_of_sync' were defined as single-bit bitfields packed into a single byte of memory.\nIn C, bitfields are not independently addressable. Consequently, any assignment to one of these flags necessitates a read-modify-write (RMW) operation on the entire byte containing all three flags. This design is inherently thread-unsafe unless all accesses are protected by a single, comprehensive lock.\nAnalysis of the implementation reveals that these flags are updated in different execution contexts without shared synchronization. The 'out_of_sync' flag is updated within the receive tasklet via smc_cdc_msg_validate(), whereas 'killed' is set within process context via smc_conn_kill().\nThe smc_conn_kill() function acquires lock_sock(), providing process-context synchronization; however, the receive path in smc_cdc_msg_recv() only acquires the bh_lock_sock(). Because the receive path does not defer to the backlog when the socket is owned by a process, there is no mutual exclusion between the process context and the tasklet context regarding these specific bitfields.\nThe exploitation flow proceeds as follows: An attacker induces a race by causing smc_cdc_msg_validate() to update 'out_of_sync' while smc_conn_kill() is performing an RMW operation on the byte containing 'killed'. When the tasklet modifies the shared byte to update 'out_of_sync', it reads the current state of the byte, modifies only the target bit, and writes the entire byte back. If smc_conn_kill() concurrently reads the byte before the tasklet's write, it effectively captures a stale state. When smc_conn_kill() subsequently performs its own write, it overwrites the tasklet's update, or conversely, the tasklet's write wipes out the change made by smc_conn_kill().\nThis race condition leads to lost updates where a socket may fail to register as 'killed' or 'freed' correctly, leading to use-after-free scenarios, memory leaks, or improper connection state transitions. Given the asynchronous nature of the tasklet and process contexts, this flaw is highly likely to manifest in heavy network traffic scenarios where connection teardown events overlap with packet validation processes."
}