CVE-2026-31637

What it actually does

The flaw is an improper input validation bug in the Linux kernel RXRPC/RXKAD authentication path. When processing a malformed RXKAD RESPONSE ticket, the kernel attempted to parse the ticket buffer even if crypto_skcipher_decrypt() failed, such as when the attacker supplied a non-block-aligned ticket length. This allowed unauthenticated network input to influence parsing of attacker-controlled bytes as if they were decrypted plaintext. Given the assigned CVSS of 9.8, the worst-case impact is full compromise of confidentiality, integrity, and availability on affected systems that expose the vulnerable RXRPC/RXKAD attack surface.

Why it matters to the business

Systems running vulnerable Linux kernels and exposing RXRPC/RXKAD-related services could be remotely attacked without credentials or user interaction, creating risk of service disruption, kernel compromise, unauthorized data access, or broader host takeover. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no public exploit maturity reported, but the network-reachable unauthenticated nature and critical CVSS score make it important to remediate in normal kernel patch cycles or faster where RXRPC/AFS/RXKAD functionality is enabled or reachable.

How an attack unfolds

An attacker first identifies a Linux system exposing RXRPC/RXKAD-capable functionality, commonly associated with RXRPC or AFS-related kernel networking paths. The attacker sends a crafted RXKAD RESPONSE containing a malformed ticket, specifically using properties such as a ticket length that is not aligned to the cipher block size so that decryption fails. In vulnerable kernels, the failure from crypto_skcipher_decrypt() is not honored, and the kernel continues parsing the ticket buffer as though it contains valid plaintext. This causes attacker-controlled bytes to be processed by kernel ticket parsing logic, potentially leading to denial of service or, depending on surrounding memory-safety conditions and kernel build details, broader compromise of the affected host. Patched kernels reject the malformed ticket and abort the connection with RXKADBADTICKET.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for RXRPC/RXKAD ticket handling, which checks the return value of crypto_skcipher_decrypt() and rejects undecryptable tickets with RXKADBADTICKET. Because no exact fixed package versions were provided, use the fixed kernel versions or vendor advisories from the relevant Linux distribution, appliance vendor, or kernel maintenance branch. Where immediate patching is not possible, reduce exposure by disabling unused RXRPC/AFS functionality, unloading or preventing use of related kernel modules where operationally safe, and restricting network access to RXRPC/AFS-related services to trusted systems only. Apply defense-in-depth controls such as host firewalls, network segmentation, and monitoring for malformed RXKAD traffic.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or image includes the vendor patch for the RXRPC change that rejects undecryptable RXKAD response tickets. Validate that all systems have rebooted into the patched kernel, not merely installed it. Review distribution security advisories and kernel changelogs for wording such as "rxrpc: reject undecryptable rxkad response tickets" or equivalent. If RXRPC/AFS functionality is not required, confirm it is disabled or inaccessible. Exposure can also be reduced by validating that related ports and services are not reachable from untrusted networks and that host firewall rules deny unsolicited access to RXRPC/AFS-related endpoints.

Typical attack path

1. Scan for hosts exposing RXRPC, AFS, or RXKAD-related network services or kernel paths.
2. Confirm the target is running a Linux kernel version containing the vulnerable RXRPC/RXKAD ticket parsing behavior.
3. Craft an RXKAD RESPONSE with a malformed encrypted ticket, such as a non-block-aligned ticket length that causes decryption to fail.
4. Send the malformed RESPONSE to the reachable RXRPC/RXKAD endpoint.
5. Trigger vulnerable kernel behavior where failed decryption is ignored and attacker-controlled bytes are parsed as plaintext ticket data.
6. Attempt to cause kernel instability, denial of service, or further exploitation depending on memory layout, mitigations, and kernel configuration.

How to detect it

To assess whether exploitation was already attempted, review kernel logs, system journals, audit logs, firewall logs, and network telemetry for RXRPC, RXKAD, AFS, or bad-ticket activity. On patched systems, malformed attempts may appear as rejected or bad RXKAD tickets, including RXKADBADTICKET-related messages if surfaced by the kernel or surrounding service stack. On vulnerable systems, look for unexplained kernel warnings, crashes, panics, oops messages, RXRPC connection aborts, or service instability temporally correlated with inbound RXRPC/AFS traffic. Network teams should review flows to UDP-based AFS/RXRPC service ports, especially traffic from unexpected external sources, repeated short-lived authentication exchanges, malformed packet alerts, or scanning across AFS-related ports. Because there are no public exploit indicators or named threat actors reported for this CVE, detection should focus on behavioral evidence: malformed RXKAD authentication attempts, unusual RXRPC connection aborts, kernel instability following RXRPC traffic, and unexpected exposure of RXRPC/AFS services.

• RXKADBADTICKET
• rxrpc
• rxkad
• AF_RXRPC
• crypto_skcipher_decrypt
• rxrpc: reject undecryptable rxkad response tickets
• undecryptable rxkad response ticket
• bad RXKAD ticket
• AFS
• udp/7000
• udp/7001
• udp/7002
• udp/7003
• udp/7004
• udp/7005
• udp/7006
• udp/7007
• udp/7008
• udp/7009

What your security team should do

• Prioritize patching Internet-facing or untrusted-network-exposed Linux systems that use RXRPC, AFS, or RXKAD-related functionality.
• Inventory Linux hosts and appliances for affected kernel versions and confirm they are rebooted into patched kernels after updates.
• If RXRPC/AFS is not required, disable or block the functionality and restrict related network access at host and network firewalls.
• Monitor kernel logs, network telemetry, and IDS/IPS alerts for malformed RXKAD/RXRPC activity, decryption failures, or repeated bad-ticket behavior.
• Because the issue is not currently KEV-listed, has low EPSS, and has no known public exploit maturity, handle as a high-severity kernel exposure with risk-based prioritization rather than confirmed active exploitation.
• Add detections for abnormal RXRPC/AFS traffic from untrusted sources, especially repeated malformed authentication exchanges or probing against AFS-related ports.