The rxrpc ACKALL handler vulnerability (CVE-2026-74430) triggers a kernel panic when an ACKALL packet arrives in unexpected protocol states. This is not merely a logic error—it exposes a fundamental gap between the state machine's implicit assumptions and its explicit state model.
The bug manifests as a NULL pointer dereference when the ACKALL handler processes a packet in a state the original code never accounted for. The original implementation implicitly assumed ACKALL would only arrive when there was something to acknowledge, but this constraint existed nowhere as an enforceable protocol state. Under normal operation this held true—but an attacker able to inject or forge ACKALL packets can trigger the unhandled state, causing the kernel to crash.
The fix introduces explicit states (RXRPC_CALL_CLIENT_PRE_SEND and RXRPC_CALL_CLIENT_AWAIT_ACK) to capture the boundary between 'connection established, nothing sent' and 'packets in flight.' This converts an implicit operational assumption into an enforceable protocol constraint. The fix also switches from tx_top to tx_transmitted for sequence number tracking—the CVE notes that tx_top had 'a looser definition,' indicating the original code carried latent ambiguity in how transmitted packets were tracked, not just in the ACKALL handler.
For defenders, the priority actions are: confirm your kernel version includes the rxrpc state machine fix; audit whether rxrpc UDP endpoints are exposed externally (the threat model question matters less than the deployment reality); and treat this as a signal to review other kernel protocol implementations for similar implicit invariant reliance. The tx_transmitted change suggests the original code may have contained layered semantic inconsistencies that the ACKALL issue merely exposed—other protocol handlers in the rxrpc call path may warrant similar scrutiny. The failure mode is a kernel panic, not service degradation, meaning a successful exploit affects the entire host rather than a single application.