CVE-2026-45998

What it actually does

This flaw is in the Linux kernel RxRPC networking code. Under memory-allocation failure conditions during packet handling, skb_unshare() can fail in a way that invalidates or clears the packet buffer pointer expected by later code, leading to unsafe use of the socket buffer state and likely a kernel oops. Because the vulnerable logic runs in kernel context, successful triggering can cause denial of service through kernel crash and may create conditions for broader kernel memory corruption impact depending on kernel configuration, allocator behavior, and exploitability on a given build.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local denial-of-service or potential privilege-impact risk if untrusted users can trigger RxRPC packet-processing paths. Operationally, exploitation is most likely to appear as unexpected kernel crashes, service interruption, host reboot, or instability on Linux servers. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so remediation should be prioritized through standard kernel patch cycles unless RxRPC/AFS functionality is used or untrusted local users have access.

How an attack unfolds

An attacker with local access first needs a way to exercise the kernel RxRPC receive path, such as by using functionality that opens or interacts with AF_RXRPC/RxRPC traffic. The attacker then attempts to create packet-processing conditions where skb_unshare() is invoked and fails, typically by combining crafted RxRPC traffic or local socket activity with memory pressure. In the vulnerable code path, failure handling can leave the parent caller with an unexpected NULL or invalid skb state. Subsequent tracing or cleanup logic may dereference or operate on that invalid state, causing a kernel oops and potentially crashing the host. Practical exploitation beyond denial of service would depend heavily on kernel build options, memory allocator behavior, enabled tracing, and whether the attacker can reliably shape kernel memory state.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the RxRPC fix moving skb unsharing into the call-packet processing path and removing the unsafe parent skb pointer handling. No exact fixed versions were provided, so use vendor advisories for the affected distribution and kernel stream to identify the first patched package. Where immediate patching is not possible, reduce exposure by disabling or avoiding RxRPC/AFS functionality if not required, restricting untrusted local shell access, limiting the ability of low-privileged users to create pressure on kernel memory, and ensuring crash recovery and high-availability controls are in place. Mitigations should be treated as temporary because the vulnerable behavior is in kernel code.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package version is at or above the vendor-fixed release containing the RxRPC skb_unshare() failure-handling patch. After rebooting into the patched kernel, confirm the active kernel with uname -a or equivalent package inventory tooling rather than only checking installed packages. Review vendor changelogs or source patches for references to the RxRPC fix, skb_unshare(), rxrpc_input_packet(), or rxrpc_input_call_packet(). To assess exposure, check whether RxRPC or AFS-related functionality is enabled or used and whether systems permit untrusted local users. Validate stability by monitoring kernel logs after patching for absence of new rxrpc-related oops or crash traces.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Identify whether RxRPC/AF_RXRPC functionality is available or in use, such as through AFS-related services or kernel support.
3. Trigger RxRPC packet processing from local code or through locally reachable RxRPC activity.
4. Apply memory pressure or otherwise attempt to force skb_unshare() allocation failure during packet handling.
5. Cause the vulnerable error path to leave skb state invalid for later processing.
6. Trigger the follow-on trace or receive-completion path, leading to a kernel oops, crash, or system instability.

How to detect it

There are no reliable remote network-only indicators for confirmed exploitation from the provided data. Detection should focus on host telemetry: kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dump systems such as kdump or apport; reboot and panic telemetry; and any audit or EDR events showing local users running tools that interact with AF_RXRPC, AFS, or unusual socket/memory-pressure activity shortly before a crash. Look for kernel oops or panic stack traces containing RxRPC functions, skb_unshare(), or receive-path functions named in the fix. Correlate those events with local user sessions, recently executed binaries, resource-exhaustion activity, and unexplained service interruption. Because this issue may manifest as a crash rather than a persistent compromise, absence of filesystem artifacts does not rule out attempted exploitation.

• rxrpc_input_packet
• rxrpc_io_thread
• trace_rxrpc_rx_done
• rxrpc_input_call_event
• rxrpc_input_call_packet
• skb_unshare
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• Call Trace:
• AF_RXRPC
• rxrpc

What your security team should do

• Inventory Linux systems and identify kernels that include RxRPC support, especially systems using AFS or AF_RXRPC-related functionality.
• Patch affected systems through the normal kernel update process and reboot into the fixed kernel; prioritize multi-user systems and systems with untrusted local access.
• If patching is delayed, disable or restrict unnecessary RxRPC/AFS functionality and limit untrusted local interactive access.
• Monitor kernel logs, crash dumps, and reboot telemetry for rxrpc-related oops traces or unexplained crashes.
• Ensure crash dump collection is enabled on high-value Linux systems so suspected exploitation or reliability incidents can be investigated.
• Track distribution advisories because exact fixed package versions vary by kernel branch and vendor backport policy.