Linux Kernel CVE-2026-31637: RxRPC RxKAD Ticket Decrypt Error Fix

Overview​

CVE-2026-31637 is a Linux kernel vulnerability in the RxRPC security path, specifically in the rxkad authentication code. The issue is small at the code level but important in principle: the kernel attempted to decrypt an RxKAD response ticket, then continued parsing the ticket buffer even if the decryption operation failed.
In practical terms, a malformed RxRPC RESPONSE packet could provide a ticket length that is not aligned to the cipher block size. That causes crypto_skcipher_decrypt() to fail. Before the fix, the return value from that decrypt operation was ignored, so the kernel could proceed as though the ticket had been successfully decrypted. The parser would then operate on bytes that were not valid plaintext and may be attacker-controlled.
The upstream fix changes the behavior so that a failed ticket decrypt is treated as a bad ticket. Instead of continuing into the ticket parser, the connection is aborted with RXKADBADTICKET.
This is not a broad “all Linux systems are instantly exploitable” vulnerability. RxRPC is a specialized Linux networking subsystem used mainly by AFS-related workloads and by software that explicitly uses the AF_RXRPC socket family. The affected code path is most relevant where RxRPC services using RxKAD authentication are enabled and reachable. Still, because the bug is inside kernel networking code, administrators should treat it as a kernel patching issue rather than as a normal application-layer problem.

What is RxRPC?​

RxRPC is a remote procedure call protocol implemented in the Linux kernel. It sits above UDP and provides a reliable call/response model. The Linux implementation exposes the AF_RXRPC socket family and is used by kernel and userspace components that need RxRPC-style communication.
A common example is AFS, the Andrew File System. AFS uses RxRPC for communication between clients and servers. In Linux, the kernel documentation describes RxRPC as a reliable two-phase transport over UDP, where a client sends a request and receives a reply. RxRPC supports virtual connections, service IDs, packet sequencing, acknowledgments, aborts, and optional security negotiation.
The relevant security mechanism here is RxKAD. RxKAD is the Kerberos 4-style security protocol historically associated with AFS. In the Linux implementation, the rxkad module handles this security layer. RxKAD uses tickets and session keys to authenticate secure RxRPC connections. During connection setup, the server can issue a challenge, the client responds, and the server validates the response before accepting the secured connection.
CVE-2026-31637 sits inside that challenge/response validation path.

The vulnerable function​

The function named in the CVE description is:
rxkad_decrypt_ticket()
This function is responsible for decrypting an RxKAD response ticket and then parsing the decrypted contents.
The vulnerable logic looked conceptually like this:

crypto_skcipher_decrypt(req);
skcipher_request_free(req);

/* parsing continues */
p = ticket;
end = p + ticket_len;

The important missing step was checking whether crypto_skcipher_decrypt(req) actually succeeded.
Cryptographic APIs do not guarantee success just because the function was called. They can fail for multiple reasons, including invalid input length, invalid block alignment, request errors, or algorithm-specific constraints. In this case, the CVE description calls out a malformed RESPONSE that uses a non-block-aligned ticket length. Block ciphers require input lengths that make sense for the cipher mode and padding behavior. If the length is invalid, the decrypt operation can fail.
The problem was that the failure did not stop the parser. The kernel continued as though the ticket buffer contained valid decrypted plaintext. That meant the ticket parser could operate on data that was never successfully decrypted.
The fix stores the return value:

ret = crypto_skcipher_decrypt(req);
skcipher_request_free(req);

if (ret < 0)
    return rxrpc_abort_conn(conn, skb, RXKADBADTICKET, -EPROTO,
                            rxkad_abort_resp_tkt_short);

In older stable branches, the exact error-handling structure can differ, but the security principle is the same: do not parse the ticket if decryption failed.

Why this matters​

Security-sensitive parsing code must be strict about state transitions. If a buffer is expected to contain decrypted, authenticated, structured data, then the code must only parse it after confirming that the decryption step succeeded.
CVE-2026-31637 is a classic example of a missing error check at a boundary between two trust states:

• Encrypted or malformed network-controlled input arrives.
• The kernel attempts to decrypt it.
• Decryption fails.
• The kernel should stop.
• Instead, vulnerable kernels continue parsing.

The vulnerability is not that the decrypt function itself is broken. The vulnerability is that its failure result was ignored.
That distinction matters for administrators and security teams because it affects how the bug should be understood. This is not a cryptographic break of RxKAD. It is not a disclosure of Kerberos secrets by itself. It is a kernel input-validation bug in the RxRPC authentication path.

Attack scenario​

A plausible attack scenario requires an attacker to interact with an RxRPC service that uses the affected RxKAD path. The attacker sends a malformed RxRPC RESPONSE containing a ticket length that causes the decrypt operation to fail. The CVE description specifically mentions a non-block-aligned ticket length.
On an unpatched kernel, the decrypt operation fails, but the parser still processes the buffer as if it were decrypted ticket plaintext. Because the input originated from a malformed network message, the parser may be driven by bytes under attacker influence.
The upstream fix changes this behavior so that failed ticket decryption results in a connection abort using RXKADBADTICKET.
The most likely operational impact is a denial-of-service or robustness issue in systems exposing the vulnerable RxRPC/RxKAD path. The public CVE text does not establish remote code execution, privilege escalation, or secret extraction. Until vendor advisories provide more detail, defenders should avoid overstating the impact. However, kernel networking bugs deserve attention because parsing untrusted network input in kernel context leaves less room for error than equivalent user-space parsing.

Exposure: who should care?​

Most general-purpose Linux desktops and servers do not actively expose RxRPC services. However, the vulnerability is relevant to environments that use or enable:

• AFS or OpenAFS-related infrastructure.
• Linux kernel AFS client functionality.
• RxRPC-based services.
• Custom software using AF_RXRPC.
• Kernel builds where RxRPC and RxKAD are enabled and reachable.
• Servers that listen for RxRPC traffic over UDP.
• Specialized academic, research, enterprise, or legacy distributed filesystem deployments.

Administrators should not assume exposure solely because the kernel contains RxRPC code. A vulnerable function being present in the kernel tree is not the same as an exposed attack surface. The key questions are:

• Is the running kernel built with RxRPC support?
• Is the rxrpc module loaded?
• Is the rxkad path available?
• Is an RxRPC service listening?
• Is that service reachable by untrusted clients?
• Is AFS or a related service in use?

If the answer to all or most of those questions is “no,” the practical risk is lower. If the answer is “yes,” patching should be prioritized.

Windows and Microsoft context​

Although the CVE is listed in Microsoft’s Security Update Guide, the vulnerability itself is in the Linux kernel. That distinction is important for Windows administrators.
A normal Windows installation is not affected simply because Microsoft lists the CVE. The affected component is Linux kernel RxRPC/RxKAD code. However, Microsoft ecosystems can still encounter the issue in several ways:

• Linux virtual machines running on Hyper-V.
• Linux workloads in Azure.
• Azure Linux or other Microsoft-maintained Linux distributions.
• AKS or Kubernetes nodes running affected Linux kernels.
• WSL 2 environments, because WSL 2 uses a real Linux kernel.
• Security scanners that ingest MSRC entries and flag mixed Windows/Linux estates.
• Enterprise vulnerability dashboards that track CVEs across all operating systems.

For WindowsForum readers, the practical message is this: do not look for a typical Windows cumulative update to fix this on Linux guests. Patch the Linux kernel inside the affected Linux environment. For WSL 2, use the Microsoft-supported WSL update path. For Linux VMs or cloud nodes, use the distribution’s kernel update mechanism.

Checking whether RxRPC is present​

On a Linux system, administrators can start with simple checks.
Check whether the RxRPC module is loaded:
lsmod | grep rxrpc
Check whether the kernel has RxRPC-related modules available:
find /lib/modules/$(uname -r) -type f | grep -E 'rxrpc|rxkad|afs'
Check the running kernel version:
uname -a
Check whether AFS-related modules are loaded:
lsmod | grep -E 'afs|rxrpc|rxkad'
Check listening UDP sockets:
ss -u -l -p
These checks do not prove vulnerability or safety by themselves. A module may be available but not loaded. A service may be reachable only internally. A distribution may have backported the patch without changing the upstream kernel version string in an obvious way. Still, these commands help determine whether the vulnerable subsystem is likely to be in active use.

Checking package status​

Because kernel fixes are frequently backported, the safest approach is to rely on your Linux vendor’s security advisories and package metadata rather than only comparing upstream version numbers.
On Debian or Ubuntu-based systems:

apt update
apt list --upgradable | grep -E 'linux-image|linux-headers|linux-modules'

Installed kernel packages can be listed with:
dpkg -l | grep -E 'linux-image|linux-modules'
On Red Hat, Fedora, Rocky, AlmaLinux, or similar systems:

dnf updateinfo list security
dnf update kernel

or on older systems:

yum updateinfo list security
yum update kernel

On SUSE-based systems:

zypper list-patches
zypper patch

On Arch-based systems:
pacman -Syu
For container hosts and Kubernetes nodes, remember that containers share the host kernel. Updating a vulnerable host kernel requires updating the node operating system and rebooting into the fixed kernel. Rebuilding application containers alone will not fix a kernel vulnerability.

Patch status and upstream fix​

The upstream fix is associated with the Linux kernel commit that changes the RxKAD ticket decrypt path to check the result of crypto_skcipher_decrypt(). Stable backports exist for some maintained kernel branches, while other long-term branches may require vendor-specific backports or later stable updates.
As of April 26, 2026, upstream kernel release information shows Linux 7.0.1 as the latest stable release, with maintained long-term branches also receiving updates. Some stable review messages show the RxRPC fix being carried into branches such as 6.6 and 6.12. Other older branches initially had automatic cherry-pick failures and required adapted backports.
This is normal for kernel stable maintenance. A patch may apply cleanly to one branch but not another because the surrounding code has changed. When that happens, maintainers prepare branch-specific backports. Administrators should therefore avoid assuming that “same CVE, same patch, same line numbers” applies across every kernel branch.
The correct remediation path is:

• Identify the running kernel.
• Check your distribution’s advisory for CVE-2026-31637.
• Install the vendor-provided fixed kernel.
• Reboot into the new kernel.
• Confirm the running kernel changed.
• If using live patching, confirm that the live patch explicitly covers this CVE or the relevant RxRPC commit.

Why rebooting matters​

Kernel package installation alone is not enough. Linux systems continue running the old kernel until rebooted, unless a live patching system applies the relevant fix in memory.
After updating, verify the active kernel:
uname -r
Compare that with the installed kernel packages:
ls /boot
or:
rpm -q kernel
or:
dpkg -l | grep linux-image
If the fixed kernel is installed but the old kernel is still running, the system remains exposed until it boots into the fixed kernel.
This is especially important on servers with long uptimes, virtualization hosts, Kubernetes nodes, and appliances where kernel updates may be installed automatically but reboots are delayed.

Temporary mitigations​

The best fix is to install a patched kernel. If immediate patching is not possible, temporary mitigations should focus on reducing exposure to the affected RxRPC path.
Possible mitigations include:

• Disable unused AFS/RxRPC services.
• Block inbound RxRPC-related UDP traffic from untrusted networks.
• Restrict access to AFS infrastructure to trusted clients.
• Unload unused rxrpc, rxkad, or AFS-related modules if operationally safe.
• Use host firewalls to limit reachability.
• Segment legacy AFS services away from general user networks.
• Prioritize patching internet-facing or broadly reachable RxRPC services.
• Audit systems where AFS is enabled automatically.

A cautious firewall approach may be appropriate where RxRPC is not expected to be reachable. However, do not block production AFS traffic without understanding the environment. AFS and RxRPC deployments can be business-critical in universities, research labs, engineering environments, and legacy enterprise systems.
To inspect loaded modules:
lsmod | grep -E 'rxrpc|rxkad|afs'
To attempt unloading unused modules:

sudo modprobe -r rxkad
sudo modprobe -r rxrpc

This will fail if the modules are in use, and that is a useful signal. Do not force-remove kernel modules on production systems.
To prevent a module from loading automatically, administrators can use modprobe blacklist configuration, but this should be tested carefully:

echo "blacklist rxrpc" | sudo tee /etc/modprobe.d/blacklist-rxrpc.conf
echo "blacklist rxkad" | sudo tee -a /etc/modprobe.d/blacklist-rxrpc.conf

This kind of mitigation is only appropriate if the system does not need RxRPC or AFS functionality.

Detection and logging​

There is no universal indicator of compromise for this CVE based only on the public description. A malformed RxRPC response may simply be dropped or may cause connection abort behavior. After patching, failed decrypts should result in RXKADBADTICKET rather than parser continuation.
Security teams can look for:

• Unexpected RxRPC traffic from untrusted sources.
• Repeated malformed authentication attempts.
• Kernel logs mentioning RxRPC, RxKAD, AFS, bad tickets, aborts, or protocol errors.
• Service instability affecting AFS or RxRPC-backed workloads.
• Network scanning against UDP ports used by AFS-related services.
• Crash reports or kernel warnings involving net/rxrpc/rxkad.c.

Useful commands include:
dmesg | grep -iE 'rxrpc|rxkad|afs|bad ticket|ticket'
journalctl -k | grep -iE 'rxrpc|rxkad|afs|bad ticket|ticket'
Packet-level monitoring may also help in high-risk environments, but many organizations will not have existing decoders or signatures for RxRPC. If RxRPC is not expected at all, any observed RxRPC traffic may be worth investigating.

Risk assessment​

At the time of publication, NVD enrichment for CVE-2026-31637 was still pending, meaning official NVD CVSS scoring and CPE mapping may not yet be complete. Some third-party databases may display provisional or independently derived scores, but administrators should treat the upstream kernel description and vendor advisories as more authoritative.
A reasonable risk assessment is:

• Affected component: Linux kernel RxRPC/RxKAD.
• Attack surface: Specialized network protocol path, not a default web or SSH service.
• Likely exposure: Low on typical desktops and general servers; higher on systems using AFS/RxRPC.
• Privileges required: Depends on deployment and reachability; malformed protocol input is central to the issue.
• User interaction: Not expected in the kernel protocol path.
• Primary concern: Kernel parsing of attacker-controlled data after failed decryption.
• Operational priority: Patch all affected kernels, prioritize exposed RxRPC/AFS services.

The vulnerability should not be ignored simply because RxRPC is uncommon. Rare subsystems can be overlooked in vulnerability management, and legacy distributed filesystem services often remain in production for years.

Guidance for enterprise administrators​

Enterprise teams should handle CVE-2026-31637 through normal kernel vulnerability management, but with special attention to asset classification.
Recommended steps:

• Query vulnerability scanners for CVE-2026-31637.
• Identify Linux systems with affected kernel packages.
• Identify systems where RxRPC, RxKAD, or AFS modules are loaded.
• Prioritize systems exposing RxRPC services to untrusted networks.
• Apply vendor kernel updates.
• Reboot or live-patch as appropriate.
• Confirm the fix is active.
• Document exceptions for systems that cannot be rebooted immediately.
• Apply network restrictions where patching is delayed.
• Re-scan after remediation.

For Kubernetes environments, focus on node images and host kernels. Containers do not carry their own independent Linux kernel. If an AKS, self-managed Kubernetes, OpenShift, or other cluster node is running an affected host kernel, the node must be updated and rebooted or replaced.
For cloud environments, check both marketplace images and custom images. Long-lived VMs may not have rebooted into patched kernels even if unattended updates installed packages.
For appliance-like Linux systems, confirm whether the vendor ships a kernel update. Do not assume you can safely install a generic upstream kernel on an appliance.

Guidance for home users and desktop users​

Most home Linux users are unlikely to be directly exposed unless they use AFS or specialized software relying on RxRPC. Even so, the correct action is simple: install normal distribution updates and reboot.
On Ubuntu, Debian, Linux Mint, Pop!_OS, or similar:

sudo apt update
sudo apt full-upgrade
sudo reboot

On Fedora:

sudo dnf upgrade
sudo reboot

On Arch:

sudo pacman -Syu
sudo reboot

After reboot:
uname -r
If your distribution has not yet published a fixed kernel, monitor its security tracker. Avoid manually replacing your distribution kernel unless you understand the support implications.

Guidance for WSL 2 users​

WSL 2 uses a Linux kernel, but it is managed differently from a normal Linux distribution kernel. Updating packages inside a WSL distribution does not necessarily update the WSL 2 kernel itself.
Users can update WSL with:
wsl --update
Then restart WSL:
wsl --shutdown
After reopening the WSL distribution, check the kernel:
uname -a
For most WSL users, exposure is likely limited because WSL is not typically running an externally reachable RxRPC service. However, developers using WSL for specialized networking or filesystem experiments should still keep the WSL kernel current.

What not to assume​

There are several easy mistakes to avoid with this CVE.
Do not assume the system is safe just because the upstream version number looks old. Distributions often backport security patches without moving to a new major kernel branch.
Do not assume the system is vulnerable only because the version number appears in a scanner result. Scanners can lag behind vendor backports or misread patched enterprise kernels.
Do not assume Windows itself is affected because MSRC lists the CVE. The vulnerable code is Linux kernel code.
Do not assume containers can be fixed by rebuilding images. Kernel vulnerabilities are fixed on the host.
Do not assume live patching covers this automatically. Confirm the live patch specifically includes the relevant RxRPC fix.
Do not assume low exposure means no action is required. Kernel updates often contain many fixes, and this one should be handled as part of routine security maintenance.

Bottom line​

CVE-2026-31637 is a Linux kernel RxRPC/RxKAD vulnerability caused by missing error handling after ticket decryption. A malformed RxKAD response ticket can cause decryption to fail, but vulnerable kernels continue into the ticket parser anyway. The fix is straightforward: check the decrypt result and abort the connection with RXKADBADTICKET when decryption fails.
The real-world risk depends heavily on whether RxRPC and RxKAD are in use and reachable. Typical Linux desktops and many servers are unlikely to expose this path, but AFS/RxRPC environments should patch promptly. Microsoft’s listing does not make this a Windows kernel issue; it matters to Microsoft-connected environments primarily through Linux workloads, WSL 2, Azure Linux systems, Linux VMs, and vulnerability management pipelines.
Administrators should install the appropriate vendor kernel update, reboot into the fixed kernel, and reduce RxRPC exposure where patching cannot be completed immediately.

---

Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center