CVE-2026-45988

What it actually does

This flaw is in the Linux kernel RxRPC/AF_RXRPC handling of cryptographic challenge-response packets. A RESPONSE packet that encounters a temporary processing failure can be left partially decrypted and then requeued, causing the kernel to process already-mutated cryptographic packet state again. That breaks the expected packet-processing invariant for RxRPC authentication and can lead to incorrect validation, protocol state corruption, kernel instability, and potentially broader confidentiality, integrity, and availability impact in systems that expose or use the affected RxRPC functionality over the network.

Why it matters to the business

Systems running affected Linux kernels may be exposed to remote, unauthenticated attack if RxRPC/kAFS-related functionality is reachable. Successful exploitation could disrupt services through kernel crashes or protocol failure and, based on the assigned severity, may also risk compromise of protected data or system integrity. The issue is not currently listed in CISA KEV, is not known to be used in ransomware, and has low EPSS at this time, but the network-reachable and unauthenticated nature of the flaw makes patching important for internet-facing or untrusted-network Linux hosts.

How an attack unfolds

An attacker first identifies a Linux system exposing or using the RxRPC protocol, commonly associated with AF_RXRPC/kAFS-style traffic. The attacker then sends crafted or adversarial RxRPC CHALLENGE/RESPONSE traffic designed to trigger a temporary error during cryptographic packet handling. On a vulnerable kernel, the affected RESPONSE packet can be left in a partially decrypted state and requeued for another processing attempt. When the kernel later retries processing that same mutated packet state, authentication and protocol handling may behave incorrectly, potentially causing denial of service, corrupting RxRPC connection state, or enabling further impact depending on kernel configuration and reachable services. The upstream fix changes the behavior so that packets encountering these error paths are discarded instead of retried, forcing a fresh challenge-response exchange.

How to fix it

Upgrade to a Linux kernel version that includes the RxRPC fix for discarding failed RESPONSE/CHALLENGE packets instead of retrying partially processed cryptographic state. Because no exact fixed package versions were provided, use the latest security kernel available from the relevant Linux distribution or vendor and confirm the vendor advisory explicitly includes the RxRPC re-decryption fix for this CVE. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by disabling unused RxRPC/kAFS functionality, preventing the affected kernel modules from loading where operationally safe, and restricting inbound and lateral network access to RxRPC/AFS-related services from untrusted networks.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, has been updated to a vendor build containing the RxRPC fix. Validate with commands such as `uname -r`, distribution package inventory tools, and vendor advisory mapping. Check whether RxRPC-related modules or functionality are present or loaded, for example AF_RXRPC, rxrpc, or kAFS-related components. Confirm compensating controls by verifying firewall policy and network telemetry do not permit unnecessary RxRPC/AFS-related traffic from untrusted sources. After remediation, monitor kernel logs for continued RxRPC warnings, kernel oops messages, BUG reports, or crashes during RxRPC activity.

Typical attack path

1. Identify Linux hosts with RxRPC/AF_RXRPC or kAFS-related functionality enabled or reachable over the network.
2. Send RxRPC traffic that initiates or interacts with the protocol challenge-response flow.
3. Trigger a temporary failure while the kernel is processing a RESPONSE packet or generating a RESPONSE to a CHALLENGE packet.
4. Cause the vulnerable kernel to requeue and retry a packet that has already been partially decrypted.
5. Leverage the resulting cryptographic/protocol state confusion to cause service disruption or pursue further impact where reachable attack surface and kernel configuration allow.

How to detect it

There are no public exploit-specific indicators in the provided intelligence, so detection should focus on evidence of suspicious RxRPC exposure and post-exploitation symptoms. Review kernel logs, system journals, crash dumps, and panic/oops reports for RxRPC, AF_RXRPC, kAFS, authentication, or packet-processing errors. Examine network telemetry, firewall logs, IDS data, and NetFlow for unusual UDP traffic to services associated with RxRPC/AFS, especially high-volume, malformed, repeated challenge-response patterns, or traffic from untrusted sources. On Linux endpoints, review module load events for rxrpc, af_rxrpc, and kafs where those components are not expected. If kernel crash dumps are available, inspect call traces for RxRPC-related functions and correlate crash timing with inbound RxRPC/AFS traffic. Because exploitation may manifest as kernel instability rather than a clean application log event, combine host crash telemetry with network-flow analysis around the same time window.

• rxrpc
• AF_RXRPC
• af_rxrpc
• kafs
• Call Trace:.*rxrpc
• BUG:.*rxrpc
• Oops:.*rxrpc
• kernel panic.*rxrpc
• udp dpt=7000
• udp spt=7000

What your security team should do

• Prioritize patching Linux systems that expose network services to untrusted networks or use kAFS/RxRPC functionality.
• Reboot patched systems and verify the active running kernel is the fixed kernel.
• Inventory systems with AF_RXRPC, rxrpc, or kAFS modules enabled or loaded; focus remediation and monitoring on those hosts first.
• If patching must be delayed, restrict inbound and lateral UDP traffic associated with RxRPC/AFS usage to trusted sources only and disable unused RxRPC/kAFS functionality where safe.
• Add monitoring for kernel crash, oops, BUG, and RxRPC-related log events, especially following unusual RxRPC/AFS network traffic.
• Track Linux distribution advisories for exact fixed kernel package versions and backport status because fixes may appear under vendor-specific kernel release numbers.
• Treat any unexplained kernel instability on hosts using RxRPC/kAFS as potentially security-relevant until logs and network telemetry are reviewed.