Cloudanix VulnDB

CVE-2026-80980

Critical · 9.8

CVSS

9.8

EPSS

0.6%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A Linux high-speed networking flaw can scramble a connection’s status when two parts of the system update it at once, which may crash the machine or break those connections until the kernel is updated.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A race in the Linux kernel SMC (Shared Memory Communications) subsystem lets concurrent writers update three 1-bit flags (killed, freed, out_of_sync) that share one byte in struct smc_connection. Each store is a read-modify-write of the other flags and they are not taken under a common lock: out_of_sync is set from the receive tasklet while killed is set from process context, and the receive path only takes bh_lock_sock(). A torn update can leave a connection incorrectly live, killed, freed, or marked out_of_sync, which can skip teardown, continue processing a dead socket, or otherwise corrupt kernel SMC state with memory-safety and availability impact.

Why it matters to the business

Hosts that use Linux SMC/RDMA for low-latency or high-throughput networking can suffer kernel panics, session corruption, or host instability that interrupts production traffic. The issue is not in CISA KEV, is not associated with ransomware, has no public exploit maturity, and EPSS is low and flat (~0.65% over 30 days), so mass opportunistic exploitation is unlikely. Residual risk is concentrated on unpatched kernels that actually load net/smc; a single crash can still take down latency-sensitive workloads.

How an attack unfolds

An attacker who can establish or influence SMC connections races CDC receive/validation against connection kill. Validation sets out_of_sync from bottom-half context while smc_conn_kill() sets killed under lock_sock(); because the flags share a byte, one store can clobber the others. The kernel may then treat a killed or freed connection as live (or the reverse), leading to use-after-free or continued processing of invalid SMC state. No named threat actors or public exploits are known.

How to fix it

Apply the upstream net/smc change that gives killed, freed, and out_of_sync each their own byte so a store no longer mutates neighboring flags (struct smc_connection grows by two bytes; boolean readers are unchanged). Install the distribution or vendor kernel that contains this fix and reboot so in-memory structures use the new layout. There is no complete userspace workaround. If SMC is not required, unload/disable SMC and related RDMA usage until patched kernels are deployed. Exact package versions were not supplied with this record—use your distro advisory for the net/smc flag-packing fix.

How to confirm the fix worked

Confirm the running kernel’s changelog or source shows killed, freed, and out_of_sync as separate bytes in struct smc_connection, not packed bitfields. Verify SMC-enabled hosts have rebooted onto that kernel. Where SMC is unused, confirm net/smc is not loaded. After patching, exercise SMC connect, disconnect, and CDC receive under concurrent teardown and watch for oopses, warnings, or connection-state anomalies.

Typical attack path

  1. Obtain the ability to participate in or influence Linux SMC connections on a vulnerable kernel.
  2. Cause CDC receive/validation and connection kill/teardown to run concurrently on the same connection.
  3. Win the unsynchronized read-modify-write race on the packed killed/freed/out_of_sync flags.
  4. Cause the kernel to act on SMC state with corrupted liveness or sync flags.
  5. Induce kernel memory corruption, unexpected control flow, or denial of service in the SMC path.

How to detect it

No public exploits or campaigns are known, so hunt for crash evidence rather than malware. Review dmesg, journalctl -k, and vmcore/oops traces for faults in net/smc receive, CDC validation, or connection-kill paths, especially around concurrent teardown. KASAN or similar use-after-free reports on SMC connection objects after kill are more relevant than network signatures. Lack of these artifacts does not prove the race never fired.

What your security team should do

  • Patch and reboot hosts that load net/smc or use SMC/RDMA first.
  • Inventory SMC/RDMA usage and disable it where it is not required.
  • Track distro kernel advisories for the net/smc flag-packing fix; no CISA KEV due date applies, but treat SMC-enabled multi-tenant or exposed systems with higher urgency given the critical scoring.
  • Monitor kernel logs for SMC-path oopses until fleets are patched; there is no evidence of in-the-wild exploitation.
  • Do not wait for public exploit code—EPSS is low and maturity is none, but the race is inherent whenever receive and kill overlap.

The record

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.

Affected packages

Ecosystem Package Introduced Fixed