CVE-2026-31676

What it actually does

This vulnerability is a race condition in the Linux kernel RxRPC subsystem. The flaw allowed duplicate or late RxRPC RESPONSE packets to be processed after a service connection had moved beyond the intended challenge state. Because response verification and security setup could be re-entered outside the correct locked state transition, an unauthenticated remote attacker could potentially trigger inconsistent connection state handling and cause kernel instability or denial of service. The CVSS impact is availability-only: confidentiality and integrity are not expected to be directly affected.

Why it matters to the business

Systems running affected Linux kernels with RxRPC-capable services exposed may be vulnerable to remote denial of service. Successful exploitation could interrupt workloads that rely on the affected kernel, including file, authentication, or distributed-service components using RxRPC-based communication. The current public exploitation signal is low: EPSS is approximately 0.0039 and stable over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. However, because the flaw is in the kernel network stack, exposed systems should still be patched through normal kernel maintenance cycles, with higher priority for internet-facing or untrusted-network systems using RxRPC.

How an attack unfolds

An attacker would target a Linux system reachable over the network on an RxRPC-using service. The attacker initiates or interacts with an RxRPC service connection and sends crafted, repeated, or late RESPONSE packets during or after the service challenge phase. On vulnerable kernels, the kernel may process those RESPONSE packets outside the intended connection state, re-running security initialization or setup logic in an unsafe order. If the race is won, the connection state can become inconsistent, potentially leading to a kernel fault, service disruption, or host-level denial of service. There is no indication from the supplied data that exploitation provides code execution, privilege escalation, or data theft.

How to fix it

Apply a Linux kernel update that includes the upstream RxRPC fix: RESPONSE packets must only be handled while the service connection remains in RXRPC_CONN_SERVICE_CHALLENGING, with state checked under the appropriate lock before response verification and security initialization. No exact fixed package versions were provided, so use the security advisory and kernel package metadata from the relevant Linux distribution or vendor to identify the corrected kernel build. After installing the fixed kernel, reboot into the updated kernel and ensure the old vulnerable kernel is not still running. Where immediate patching is not possible, reduce exposure by disabling unused RxRPC-dependent services, restricting access to RxRPC-related network services to trusted networks, and applying host or network firewall controls to limit unauthenticated access.

How to confirm the fix worked

Confirm the running kernel version after reboot, not just the installed package version. Compare the active kernel against the vendor advisory or changelog for this issue and verify that the RxRPC fix is included. Review whether RxRPC functionality is actually in use by checking loaded modules, kernel configuration, and active services that depend on RxRPC. Validate that network exposure is limited to expected trusted sources. For high-assurance validation, review the kernel source or vendor patch notes for logic equivalent to processing RESPONSE packets only while the connection is in RXRPC_CONN_SERVICE_CHALLENGING and performing the state check under the connection state lock.

Typical attack path

1. Identify a Linux host exposing an RxRPC-based service or functionality reachable from the attacker-controlled network.
2. Establish or interact with an RxRPC service connection that enters the service challenge phase.
3. Send duplicate, delayed, or intentionally timed RESPONSE packets around the challenge-to-secured state transition.
4. Trigger the vulnerable race condition by causing response verification or security setup to be re-entered after the connection state has changed.
5. Cause kernel instability, service disruption, or denial of service if the race condition is successfully exercised.

How to detect it

Look for evidence of kernel instability or denial-of-service conditions correlated with RxRPC traffic. Useful log sources include kernel logs, system journal entries, crash dump metadata, network flow records, firewall logs, and packet captures for services using RxRPC. Search for kernel oops, panic, lock warning, use-after-state, or general protection fault messages that mention RxRPC, rxrpc, af_rxrpc, service challenge handling, or connection state transitions. In network telemetry, look for unusual bursts of RxRPC RESPONSE-like traffic, repeated connection setup attempts, abnormal retries, or high-rate packets from a single source to RxRPC-exposed services shortly before a crash or service outage. Because this issue does not define a unique payload signature in the supplied data, absence of these artifacts does not prove non-exploitation; prioritize correlation of RxRPC traffic spikes with kernel faults or unexpected reboots.

• rxrpc
• af_rxrpc
• RXRPC_CONN_SERVICE_CHALLENGING
• kernel: rxrpc
• kernel: af_rxrpc
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• WARNING: CPU:
• Call Trace:
• service challenge
• RESPONSE

What your security team should do

• Inventory Linux systems that expose RxRPC-based services or have RxRPC functionality enabled, prioritizing internet-facing and untrusted-network systems.
• Patch affected Linux kernels through the applicable distribution or vendor update channel, then reboot to activate the fixed kernel.
• If patching is delayed, restrict network access to RxRPC-using services and disable unnecessary RxRPC-dependent functionality.
• Monitor kernel logs for crashes, warnings, or RxRPC-related errors that could indicate attempted exploitation or instability.
• Because EPSS is low, stable, and the issue is not in CISA KEV, prioritize based on exposure and service criticality rather than emergency response, unless vendor advisories indicate active exploitation in a specific distribution.