CVE-2026-46012

What it actually does

This vulnerability is a memory leak in the Linux kernel's RxRPC Kerberos authentication handling, specifically in rxkad_verify_response(). Under certain error or cleanup paths, allocated ticket and server key memory may not be freed. A local user able to exercise the affected RxRPC code path can repeatedly trigger the leak, causing unreclaimed kernel memory consumption and potentially leading to memory pressure, degraded system performance, or denial of service. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and impact limited to availability.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable by exhausting kernel memory. For organizations running workloads on Linux hosts, this may cause service interruptions, application failures, node reboots, or degraded performance. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, and has a very low EPSS score, so urgency is lower than for remotely exploitable or actively exploited kernel flaws; however, multi-user systems, shared compute platforms, container hosts, and systems exposing or using RxRPC functionality should still be prioritized for kernel updates.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient privileges to invoke the vulnerable RxRPC authentication behavior. They then cause the kernel to process crafted or repeated RxRPC/RxKAD authentication responses that drive rxkad_verify_response() through paths where allocated ticket or key structures are not released. By repeatedly triggering the condition, the attacker gradually consumes kernel memory. If memory pressure becomes severe enough, the system may slow down, terminate processes, fail allocations, or become unavailable. There is no indication from the provided data of public exploit code, active exploitation, ransomware use, privilege escalation, or data disclosure associated with this issue.

How to fix it

Apply a Linux kernel update that includes the upstream fix for rxrpc: rxkad_verify_response() memory leak handling. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, vendor, or kernel maintenance stream. After updating, reboot into the patched kernel and remove or avoid booting older vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by disabling or blocking use of RxRPC/AF_RXRPC where it is not required, limiting local shell access, applying least-privilege controls, and monitoring for memory exhaustion symptoms. Mitigations should be treated as temporary because they may not fully prevent local exploitation if the vulnerable code path remains reachable.

How to confirm the fix worked

Confirm the system is running a vendor kernel that includes the rxrpc rxkad_verify_response() memory leak fix, not merely that the package has been installed. Validate by checking the active kernel version after reboot and comparing it with the distribution's security advisory or changelog for this issue. Where source or build metadata is available, confirm the RxRPC fix that initializes the ticket pointer and funnels cleanup through a common epilogue is present. Operationally, verify that memory usage remains stable during legitimate RxRPC activity and that no unexpected kernel memory growth occurs under regression testing. If RxRPC is not needed and has been disabled, confirm the module or functionality cannot be loaded or used according to local hardening policy.

Typical attack path

1. Obtain local low-privileged access to an affected Linux system.
2. Determine that the kernel includes the vulnerable RxRPC/RxKAD code path and that the functionality can be exercised locally.
3. Generate repeated RxRPC authentication activity that reaches rxkad_verify_response() and triggers the leaking cleanup path.
4. Continue triggering the condition to consume unreclaimed kernel memory.
5. Cause memory pressure that degrades system performance, disrupts services, or results in denial of service.

How to detect it

Detection should focus on evidence of repeated local triggering of RxRPC behavior followed by abnormal kernel memory pressure. Review kernel logs, system journals, audit logs, and endpoint telemetry for unusual RxRPC-related activity, repeated module loading or socket use, rapid increases in kernel memory consumption, out-of-memory killer activity, hung tasks, service crashes, or unexpected reboots. Useful log sources include journalctl, dmesg, /var/log/kern.log, /var/log/messages, auditd, EDR process telemetry, and system performance metrics. Because this is a memory leak rather than code execution, there may be no reliable exploit-specific artifact; absence of a unique IOC does not rule out exploitation. Investigate local users or processes active immediately before memory exhaustion, especially processes repeatedly creating RxRPC sockets or interacting with AFS/RxRPC components. If threat hunting is performed, correlate low-privileged user activity with kernel memory growth and OOM events over time.

• rxrpc
• AF_RXRPC
• kAFS
• Out of memory
• oom-killer
• invoked oom-killer
• Memory allocation failure
• hung task
• kernel: rxrpc
• kernel: kafs
• /proc/net/rxrpc
• /proc/net/rxrpc_calls
• /proc/net/rxrpc_conns
• /proc/net/rxrpc_peers
• /proc/net/rxrpc_locals

What your security team should do

• Inventory Linux systems, prioritizing multi-user hosts, shared compute platforms, container hosts, and systems that use AFS/RxRPC-related functionality.
• Track distribution advisories and deploy the first available vendor kernel update containing the RxRPC rxkad_verify_response() memory leak fix.
• Reboot systems after patching and verify the running kernel is the patched version.
• If patching is delayed, restrict local interactive access and disable or limit RxRPC functionality where business requirements allow.
• Monitor affected systems for unexplained kernel memory growth, out-of-memory events, service restarts, and availability degradation.
• Because there is no known KEV listing, ransomware association, or mature exploit reported in the input, prioritize this below actively exploited remote vulnerabilities but include it in normal kernel patch cycles.