CVE-2026-64541

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network

The vulnerable handler is driven entirely by a CDC control message sent by the remote SMC-R peer over the RDMA link, with an attacker-chosen `token` field and no local syscall involvement. SMC-R runs over RoCEv2 (IP/UDP-routable, port 4791) with the CLC handshake over plain TCP, and SMC-Rv2 explicitly supports non-local/routed peers, so the attacker need not share an L2 segment.

AC:LAttack complexity, low

The attacker controls both sides of the race: it chooses when to emit CDC messages and which connection to target (the alert token is disclosed to it in the CLC accept/confirm), and it can drive the teardown side itself via CDC close/abort flags into `smc_close_passive_work()` or a stale seqno with `failover_validation` into `abort_work` -> `smc_conn_kill()`. The race can be retried indefinitely across many connections in the same link group, and was reproduced in practice with soft-RoCE.

PR:NPrivileges required, none

Establishing an SMC-R connection to a listening SMC socket requires no credentials — SMC has no authentication layer of its own, exactly like plain TCP. Everything after connection establishment (sending CDC messages with a chosen token, signalling close/abort) is available to an unauthenticated peer.

UI:NUser interaction, none

The CDC message is processed in a softirq tasklet from the RDMA completion queue with no involvement from any local user or application action. No victim interaction of any kind is needed.

S:UScope, unchanged

The corruption is confined to kernel memory within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed. This is a standard in-kernel use-after-free.

C:HConfidentiality impact, high

The freed `smc_sock` is reused type-safely as another live socket, so attacker-supplied cursors applied by `smc_cdc_msg_recv_action()` break the `0 <= bytes_to_rcv <= rmb_desc->len` invariant and make `smc_rx_recvmsg()` hand stale RMB contents to userspace, while the urgent-data path reads `*(base + conn->urg_curs.count - 1)` at an attacker-chosen offset. Once the slab page is reclaimed after the RCU grace period, reuse is unconstrained, giving a general kernel-memory read primitive.

I:HIntegrity impact, high

`sock_hold()` on an already-zero refcount followed by `sock_put()` re-enters `sk_free()`, yielding a double free, and the handler additionally writes `sk_err`/`sk_shutdown`, makes indirect calls through `sk_data_ready()`/`sk_write_space()`, and `queue_work()`s a freed `work_struct`. These are classic heap-spray and control-flow-hijack primitives leading to arbitrary kernel write.

A:HAvailability impact, high

The reported symptom is `refcount_warn_saturate` from `smc_cdc_msg_recv()`, which is an immediate kernel panic on `panic_on_warn` systems, and dereferencing freed memory in softirq context otherwise oopses. The attacker can trigger it repeatedly without authentication.