CVE-2026-43295

What it actually does

This is a local Linux kernel memory-management flaw in the RapidIO subsystem. During RapidIO network scan allocation, if an ID table allocation fails before the network object is registered, the error path can leave a stale pointer associated with the master port. Later kernel activity may dereference or free memory that is no longer valid, resulting in a use-after-free or dangling-pointer condition. The practical impact is primarily availability: a local user or local process with the ability to trigger the affected kernel path could cause a kernel crash, panic, or system hang. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service interruption, workload disruption, node reboots, failed jobs, or degraded availability for systems using or exposing the affected RapidIO kernel functionality. Because exploitation requires local access and there is no known public exploit or CISA KEV listing, broad internet-scale exploitation is unlikely; however, shared compute platforms, multi-user Linux systems, appliances, embedded systems, or specialized environments using RapidIO should treat this as a reliability and denial-of-service risk. The low EPSS score suggests low near-term exploitation probability, but kernel availability bugs can still be operationally significant where uptime is critical.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with sufficient privileges to interact with code paths that trigger RapidIO network scanning or initialization behavior. The attacker then causes an allocation failure or error condition during RapidIO scan allocation before the network object is registered. In the vulnerable path, cleanup can leave the RapidIO master port referencing memory that should no longer be used. Subsequent kernel activity involving that RapidIO structure may touch the dangling pointer, leading to invalid memory access, kernel oops, panic, or system instability. There is no indication from the provided intelligence that this vulnerability is being exploited in the wild, used by ransomware, or associated with named threat actors.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix replacing the inappropriate RapidIO cleanup path with direct kfree() handling and clearing the master-port net pointer when allocation fails. No exact fixed package versions were provided, so use vendor-specific advisories for the affected distribution, appliance, or embedded platform to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or unloading unused RapidIO functionality if operationally safe, removing unneeded RapidIO kernel modules, restricting local shell access, limiting who can load kernel modules or access RapidIO-related device interfaces, and applying standard local privilege and workload isolation controls. Kernel live patching may be an option if offered by the operating system vendor, but a reboot into a fixed kernel is typically the most reliable remediation.

How to confirm the fix worked

Confirm that systems are running a vendor kernel that contains the RapidIO fix for this issue. Validate by checking the installed and booted kernel versions, not only the package repository state. Review vendor changelogs or source patches for references to the RapidIO change in rio_scan_alloc_net(), specifically replacing rio_free_net() with kfree() on the pre-registration allocation-failure path and setting the master port net pointer to NULL. If RapidIO is not required, confirm related modules are not loaded and cannot be autoloaded. After remediation, monitor kernel logs under representative workloads for absence of RapidIO-related kernel oops, KASAN use-after-free reports, general protection faults, or panic events.

Typical attack path

1. Gain local access to an affected Linux system.
2. Identify whether the running kernel includes the affected RapidIO code and whether RapidIO functionality is present or loadable.
3. Trigger RapidIO scan allocation behavior under conditions that cause ID table allocation failure or cleanup handling.
4. Cause the kernel to retain or later dereference a dangling RapidIO master-port pointer.
5. Induce a kernel oops, panic, hang, or reboot, resulting in denial of service.

How to detect it

To determine whether exploitation or attempted triggering already occurred, review kernel and system logs for crashes, oops reports, panic messages, watchdog resets, or memory-safety diagnostics involving the RapidIO subsystem. Useful log sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, hypervisor reset events, and availability monitoring alerts showing unexpected reboots. Search for RapidIO-related function names, module names, and generic kernel memory-corruption signatures close in time to unexpected reboots or hangs. If KASAN, KFENCE, SLUB debugging, or kernel crash dumping is enabled, examine reports for use-after-free, invalid free, NULL pointer, or dangling pointer behavior in RapidIO scan allocation paths. There are no known network indicators because exploitation is local and kernel-internal.

• rio_scan_alloc_net
• rio_free_net
• rapidio
• RapidIO
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• Unable to handle kernel NULL pointer dereference
• use-after-free in rio_scan_alloc_net
• use-after-free in rio_free_net

What your security team should do

• Prioritize patching affected Linux systems where RapidIO hardware, RapidIO drivers, embedded backplanes, telecom infrastructure, industrial systems, or specialized high-availability appliances are in use.
• Use vendor advisories to identify the first fixed kernel package for each supported distribution or product, then upgrade and reboot into the corrected kernel.
• Inventory systems with RapidIO support enabled by checking kernel configuration, loaded modules, hardware inventory, and boot logs.
• If RapidIO is not required, disable or blacklist the relevant RapidIO modules as a compensating control.
• Restrict local access to affected systems, especially multi-user servers, shared compute environments, build hosts, and appliances where untrusted users or workloads may execute code.
• Monitor kernel logs for crashes or memory-safety warnings involving RapidIO, rio_scan_alloc_net(), rio_free_net(), or use-after-free reports.
• Because this is not listed in KEV, has no known ransomware association, and has very low EPSS, handle through normal kernel patch governance unless the affected systems support critical availability-sensitive services.