CVE-2026-43463

What it actually does

This flaw is in the Linux kernel AFS/RXRPC code path. The function rxrpc_kernel_lookup_peer() can return an encoded error pointer as well as NULL, but affected callers only checked for NULL. If an error pointer is treated as a valid peer object, subsequent kernel code can dereference an invalid address, leading to a kernel oops or panic. The practical impact is local denial of service against systems with the affected AFS/RXRPC functionality present and reachable; the published CVSS vector indicates local access with low privileges is required, with no confidentiality or integrity impact expected.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, failed workloads, node reboots, or degraded availability for applications relying on those hosts. Risk is highest on systems where AFS or RXRPC kernel functionality is enabled, loaded, or used. This issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a very low EPSS score, so broad exploitation is not expected; however, availability-sensitive servers should still receive the vendor kernel fix through normal patching because kernel denial-of-service flaws can have outsized operational impact.

How an attack unfolds

An attacker first needs local access to an affected Linux system, typically as an unprivileged or low-privileged user. The attacker then exercises kernel functionality that reaches the AFS client path using RXRPC peer lookup. Under an error condition from rxrpc_kernel_lookup_peer(), such as allocation failure or another lookup failure returning an encoded error pointer, vulnerable AFS callers fail to recognize the error pointer and continue as if a valid peer object was returned. When the kernel later uses that invalid pointer, it can trigger an invalid memory access, causing an oops, panic, or system crash. Exploitation is therefore focused on forcing a reliability failure rather than stealing data or gaining code execution.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that includes the AFS/RXRPC fix for this issue. Because no exact fixed package versions were provided, use the vendor advisory, kernel changelog, or stable kernel release notes to identify the corrected build containing the change that makes rxrpc_kernel_lookup_peer() return proper errors and updates AFS callers to use IS_ERR()/PTR_ERR(). Where immediate patching is not possible, reduce exposure by disabling or unloading unused AFS and RXRPC kernel modules where operationally safe, preventing untrusted local users from accessing affected systems, and applying resource controls that reduce the ability of local users to create memory pressure or repeatedly exercise the vulnerable path. Reboot into the patched kernel after installation; installing kernel packages alone is not sufficient until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor build containing the fix. Validate with commands such as uname -r, package-manager queries, and vendor advisory mapping for the corrected kernel release. Check whether AFS/RXRPC functionality is present or loaded using module and configuration inspection, such as lsmod for afs and rxrpc, modinfo where available, and kernel configuration checks for CONFIG_AFS and CONFIG_AF_RXRPC. Review kernel changelogs or source patches for the presence of the corrected error handling around rxrpc_kernel_lookup_peer() and AFS callers using IS_ERR()/PTR_ERR(). After remediation, confirm the system has been rebooted into the patched kernel and monitor kernel logs for absence of recurring AFS/RXRPC oops or panic events.

Typical attack path

1. Obtain local access to an affected Linux host with sufficient ability to exercise AFS/RXRPC-related kernel paths.
2. Determine whether AFS/RXRPC support is available, built in, or loadable on the system.
3. Trigger AFS operations that cause the kernel to perform RXRPC peer lookup.
4. Induce or wait for an error-return condition from rxrpc_kernel_lookup_peer(), such as memory pressure or peer lookup failure.
5. Cause the vulnerable caller to treat the encoded error pointer as a valid peer object.
6. Trigger a kernel oops or panic, resulting in denial of service or reboot depending on system configuration.

How to detect it

To determine whether this was already exploited or triggered, review kernel and system logs for oops, panic, invalid pointer dereference, or page fault events involving AFS or RXRPC functions. Useful sources include journald kernel logs, dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump infrastructure, kdump/vmcore records, and endpoint telemetry that captures kernel panics or unexpected reboots. Look for stack traces containing rxrpc_kernel_lookup_peer, afs, or rxrpc shortly before a reboot, node eviction, service outage, or watchdog reset. Because the flaw is a denial-of-service condition and not a typical remote compromise path, there may be no durable attacker artifact beyond kernel crash evidence and local activity preceding the crash. Correlate crash timing with local user sessions, container jobs, batch tasks, memory pressure events, module loads, and repeated AFS-related operations. Absence of these strings does not prove non-exploitation, especially if logs were lost during panic or volatile logs were not persisted.

• rxrpc_kernel_lookup_peer
• afs
• rxrpc
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• general protection fault
• /sys/module/afs
• /sys/module/rxrpc
• CONFIG_AFS
• CONFIG_AF_RXRPC

What your security team should do

• Prioritize patching availability-sensitive Linux systems and systems that allow local shell, batch, container, build, research, or shared-user workloads.
• Inventory Linux hosts where AFS or RXRPC support is enabled, loaded, or operationally required, and patch those first.
• If AFS/RXRPC is not required, disable or unload the related kernel modules according to vendor-supported hardening guidance.
• Ensure kernel updates are followed by reboot orchestration so systems actually run the fixed kernel.
• Restrict untrusted local user access on unpatched systems and monitor for repeated attempts to exercise AFS/RXRPC paths or create memory pressure.
• Add temporary monitoring for kernel oops, panic, and AFS/RXRPC stack traces until patch coverage is complete.
• Track vendor advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.