CVE-2026-43500

What it actually does

This is a Linux kernel memory-corruption vulnerability in the RxRPC networking subsystem. The vulnerable code can decrypt or authenticate DATA/RESPONSE packets in place even when the socket buffer contains externally shared paged fragments, such as fragments created through splice-based UDP paths or chained fragment lists. Because those pages may be shared or externally owned, RxRPC security operations can operate on memory they should first have copied or unshared. A local attacker with the ability to interact with the relevant networking paths can potentially corrupt kernel memory, leading to privilege escalation, information disclosure, or kernel crash.

Why it matters to the business

Successful exploitation can give a local attacker full control of an affected Linux host or cause service outages through kernel crashes. The high EPSS score, weaponized exploit maturity, and reported activity associated with the “Dirty Frag” threat context make this a high-priority kernel patching issue, especially for multi-user systems, container hosts, shared compute platforms, developer workstations, and servers where untrusted local code can run. Although it is not currently listed in CISA KEV and is not marked as ransomware-associated, the impact is severe because exploitation occurs in kernel space and can undermine host isolation.

How an attack unfolds

An attacker first obtains the ability to execute local code on an affected Linux system, such as through a low-privileged shell, compromised user account, container escape staging position, or workload execution context. The attacker then exercises kernel networking behavior involving RxRPC and socket buffers with paged fragments that are shared or externally owned. In vulnerable kernels, certain RxRPC DATA or RESPONSE packet handling paths only make a safe private linear copy when the socket buffer is cloned, but fail to do so when the buffer contains shared fragments or a fragment list. The attacker shapes traffic and buffer state so the RxRPC security operation processes those fragments in place through scatter-gather crypto handling. This can result in kernel memory corruption. Depending on exploit reliability and kernel configuration, the attacker may use the corruption to crash the system, disclose sensitive memory, or gain elevated privileges in the kernel context.

How to fix it

Upgrade to a kernel version that includes the RxRPC fix that unshares socket buffers not only when skb_cloned() is true, but also when skb_has_frag_list() or skb_has_shared_frag() is true before RxRPC security operations. Use vendor-supplied kernel updates for the affected distribution or appliance, because fixed versions vary by downstream kernel branch and backport status. Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly states this issue is covered. Where immediate patching is not possible, reduce exposure by disabling or preventing use of the RxRPC/AF_RXRPC functionality if it is not required, restricting local shell access, tightening container workload permissions, blocking untrusted code execution, and applying least-privilege controls to users and services. Treat mitigation as temporary because the vulnerability is weaponized and affects kernel memory safety.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the RxRPC shared-fragment unshare fix. Validate using the distribution’s security advisory, package changelog, or kernel source/backport notes rather than relying only on upstream version numbers. After patching, reboot and verify the active kernel with uname or the platform’s package inventory. If RxRPC is not required and has been disabled, confirm the module/functionality cannot be loaded or used by unprivileged workloads. For exposure assessment, inventory Linux systems, identify running kernel versions, check whether RxRPC support is built in or available as a module, and prioritize systems that allow local users, containers, CI jobs, or other untrusted code execution.

Typical attack path

1. Gain local code execution on an affected Linux host with low privileges.
2. Identify that the running kernel includes the vulnerable RxRPC packet handling logic and that relevant kernel functionality is available.
3. Create or influence socket-buffer conditions involving paged fragments, shared fragments, or fragment lists.
4. Trigger RxRPC DATA or RESPONSE processing so the vulnerable in-place security operation handles externally shared fragment pages.
5. Leverage the resulting kernel memory corruption to crash the host, disclose memory, or escalate privileges.
6. Use elevated privileges to disable defenses, access sensitive data, persist, or move laterally.

How to detect it

Look for signs of prior local privilege escalation or kernel instability rather than relying on a single definitive network indicator. Relevant log sources include kernel logs, system journal, audit logs, endpoint detection telemetry, process execution logs, container runtime logs, and crash dump infrastructure. Search for kernel oops, panic, general protection fault, KASAN, or slab corruption events that reference RxRPC, socket buffers, scatter-gather crypto handling, or the vulnerable functions. Investigate suspicious sequences where an unprivileged process performs unusual networking or splice-heavy activity, followed by a kernel fault, privilege boundary change, root shell, credential access, module loading, tampering with security tools, or persistence creation. If crash dumps are available, inspect stack traces for RxRPC packet handling paths such as rxrpc_input_call_event() or rxrpc_verify_response(). Threat hunting should also account for the reported “Dirty Frag” context by correlating local privilege escalation behavior with post-exploitation actions such as new privileged accounts, modified sudoers files, changed SSH authorized keys, unexpected setuid binaries, or disabled logging.

• rxrpc_input_call_event
• rxrpc_verify_response
• skb_to_sgvec
• skb_has_shared_frag
• skb_has_frag_list
• AF_RXRPC
• rxrpc
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• KASAN:
• slab-out-of-bounds
• use-after-free
• Dirty Frag

What your security team should do

• Patch affected Linux kernels as a priority, especially on shared, multi-user, container, virtualization, CI/CD, and internet-facing service hosts where local code execution paths may exist.
• Reboot systems after kernel update and verify the patched kernel is the active booted kernel.
• If patching must be delayed, disable or restrict RxRPC/AF_RXRPC where operationally feasible and harden local execution paths.
• Hunt for kernel crashes, oops traces, privilege-escalation artifacts, and unusual activity involving RxRPC-related kernel call paths.
• Review endpoint telemetry for low-privileged processes spawning privileged shells or modifying persistence mechanisms after kernel fault events.
• Increase monitoring for systems associated with the reported “Dirty Frag” exploitation context and treat suspicious local privilege escalation as potentially related.
• Prioritize remediation despite non-KEV status because the EPSS score is high and exploit maturity is listed as weaponized.
• Ensure container hosts are patched quickly; kernel vulnerabilities can cross workload boundaries even when the initial code execution is confined.