CVE-2026-64026

What it actually does

This is a Linux kernel memory/page-cache corruption issue in the rxrpc subsystem. The flaw occurs when encrypted rxrpc DATA packets transmitted locally via splice() are decrypted in place while packet buffers are shared with kernel page-cache-backed data structures. Because the sk_buff contents can be modified during receive/decrypt handling, data that should remain immutable can be corrupted. A local authenticated user able to exercise rxrpc socket behavior can potentially trigger kernel memory corruption, leading to denial of service, data corruption, information disclosure, or local privilege escalation depending on kernel configuration, rxrpc availability, and exploit reliability.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised workload on a Linux system to crash the host, corrupt data, or potentially gain elevated privileges. This is most relevant for multi-user Linux servers, shared compute platforms, container hosts, developer workstations, and systems where untrusted local users or workloads can interact with kernel networking features. The vulnerability is not listed in CISA KEV, has no known mature public exploit based on the provided data, and has a low EPSS score, so urgency is lower than for actively exploited internet-facing vulnerabilities; however, kernel memory corruption flaws should still be remediated during the next appropriate maintenance window, especially on shared or high-value systems.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux kernel. They then exercise the rxrpc protocol path, specifically conditions involving locally transmitted DATA packets and splice()-based data movement. By causing the kernel to decrypt rxrpc packet data in place while the packet buffer is still shared with page-cache-backed memory, the attacker can induce corruption of data structures that the kernel assumes are stable. With only a crash-oriented trigger, this may result in a denial of service. A more advanced exploit would attempt to shape the corrupted memory or page-cache contents to influence subsequent kernel behavior, potentially escalating privileges or disclosing sensitive data. Exploitability is dependent on whether rxrpc is present/enabled, reachable by local users, and how the affected kernel build handles rxrpc, crypto, sk_buff, and splice interactions.

How to fix it

Upgrade to a Linux kernel version that includes the upstream rxrpc fix for this issue. Because no exact affected products or fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or vendor once available. Prioritize shared systems, container hosts, build servers, HPC environments, and any Linux hosts where untrusted local users or workloads can run code. If immediate patching is not possible, consider reducing exposure by disabling or preventing loading of the rxrpc kernel module where it is not required, restricting untrusted local shell/container access, enforcing strong workload isolation, and monitoring for unexpected AF_RXRPC usage. Mitigations are not a substitute for applying the kernel fix because the vulnerability is in kernel receive/decrypt handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or kernel build includes the rxrpc change that copies DATA packet contents into a separate bounce buffer before decryption rather than decrypting shared sk_buff data in place. Validate with the distribution advisory, changelog, or kernel commit history for the running kernel. On hosts where rxrpc is not required, verify that the rxrpc module is not loaded and cannot be loaded by untrusted users. Practical exposure checks include reviewing kernel configuration for CONFIG_AF_RXRPC, checking loaded modules with lsmod, checking /proc/modules for rxrpc, and confirming the active kernel version with uname -a or distribution package tooling. Regression testing should include workloads that use rxrpc, splice(), and MSG_PEEK behavior if those features are relevant in the environment.

Typical attack path

1. Gain local low-privileged access to a Linux system running a vulnerable kernel.
2. Determine whether rxrpc/AF_RXRPC functionality is available in the kernel or as a loadable module.
3. Create or interact with rxrpc sockets and arrange local DATA packet transmission paths that involve splice()-based data movement.
4. Trigger receive/decrypt handling that modifies shared packet data in place.
5. Cause page-cache or kernel memory corruption, leading to a kernel crash, corrupted data, information exposure, or potentially privilege escalation.
6. If pursuing privilege escalation, repeatedly shape heap/page-cache state and trigger the bug until controlled corruption produces elevated execution or credential modification.

How to detect it

There are no definitive public exploitation indicators in the provided data, and successful exploitation may leave only generic kernel instability or memory-corruption artifacts. To investigate possible prior exploitation, review kernel logs, crash dumps, audit logs, endpoint telemetry, and module-loading history for rxrpc activity near unexplained crashes or data corruption. Useful log sources include journalctl/kern.log/dmesg, kdump/vmcore analysis, auditd syscall telemetry if enabled, eBPF/EDR process telemetry, module load events, and container runtime logs on shared hosts. Look for unexpected loading or use of rxrpc/AF_RXRPC, suspicious local processes creating rxrpc sockets, repeated splice() activity associated with rxrpc sockets, kernel Oops/panic reports referencing rxrpc, sk_buff, skb, page cache, crypto decrypt paths, recvmsg(), or splice(). Absence of these artifacts does not prove non-exploitation because local kernel memory-corruption attempts may not produce clean logs before a crash.

What your security team should do

• Inventory Linux systems and identify kernels that include rxrpc support, especially shared servers and systems that allow local users or untrusted workloads.
• Apply vendor-provided kernel updates that include the rxrpc fix; reboot systems as required so the patched kernel is actually running.
• Treat multi-tenant Linux hosts, container hosts, CI/build infrastructure, and research/HPC systems as higher priority because local privilege-escalation impact is more consequential there.
• If rxrpc is not needed, disable or block the rxrpc module as a temporary hardening measure until patching is complete.
• Review local access controls and workload isolation to reduce the ability of low-privileged users or containers to exercise kernel attack surface.
• Monitor for kernel crashes, rxrpc-related warnings, unexpected module loads, and unusual local use of AF_RXRPC or splice-heavy workloads.
• Because no known exploitation or KEV listing is provided, prioritize this below actively exploited remote vulnerabilities but do not defer indefinitely due to the high-impact kernel memory-corruption class.