CVE-2026-72469

CVE-2026-72469 is a reference count underflow in the rpcrdma_cm_event_handler() path, but framing it as 'a missing put' misses the real story. The bug is a state machine that assumed event ordering as an implicit invariant — and lost. The handler receives RDMA-CM events (ADDR_CHANGE, ESTABLISHED, DISCONNECTED, etc.) and processes them through a falling-through-to-disconnect model: any unexpected event triggers teardown. This worked in practice because ADDR_CHANGE historically arrived after ESTABLISHED, but the RDMA-CM API never contracted that ordering. When ADDR_CHANGE arrives first — a race condition now reproducible in certain hardware configurations and network namespace setups — the handler calls ep_put() on a reference that was never issued for that event path. The reference count drops below zero, and subsequent operations that expect the endpoint to be valid will use-after-free or corrupt state. The fix uses xchg() on re_connect_status to dispatch based on what state preceded the event, rather than treating all events uniformly. This is correct but it does something more: it codifies a behavioral assumption that was previously invisible. The connect-time get in rpcrdma_xprt_connect() — issued to protect the endpoint during rpcrdma_post_recvs() — now has semantic coupling to the event handler. The fix effectively documents through code what was previously documented only through unstated assumption. That's progress, but it's a localized fix to a structural problem. The broader question is whether this handler architecture is endemic. RDMA-CM presents a state machine interface but delivers asynchronous hardware events. Every consumer that trusts the happy-path ordering — and based on this CVE, many do — is exposed to the same race. The xchg() approach is the right fix for this instance, but it doesn't change the handler's fundamental architecture: it's still a falling-through-to-disconnected model that requires every event path to reason about current state. That's exactly the assumption that failed here. What you should do: audit rpcrdma_cm_event_handler() and any similar RDMA-CM consumers for the same implicit ordering dependency. If other handlers assume ESTABLISHED precedes all other events, they're vulnerable to analogous races. The test coverage question matters too — if out-of-sequence event delivery was never fuzzed or stress-tested in CI, this class of bug likely exists elsewhere in the subsystem. The fix closes one instance; the exposure window for the pattern remains open until the architectural assumption is examined across all RDMA-CM call sites.

Reviewed through automated stages and approved by a human before publication.