CVE-2026-64188

What it actually does

This is a use-after-free flaw in the Linux kernel Qualcomm RMNET network driver. During RMNET link deletion, an endpoint is removed from an RCU-protected hash table and freed immediately, while receive-path RCU readers may still dereference the same endpoint, specifically the egress_dev pointer. A local actor able to create/delete RMNET links and drive packet reception through the affected path could trigger a kernel memory safety violation. The most direct impact is a kernel crash or denial of service; depending on allocator state, kernel configuration, and exploit primitives available to the attacker, memory corruption could potentially be explored further, but no public exploit maturity is currently indicated.

Why it matters to the business

Systems using affected Linux kernels with the RMNET driver enabled may be vulnerable to local denial of service, causing host crashes, service interruption, failed workloads, or device instability. This is most relevant to Linux systems, embedded platforms, Android-derived devices, or telecom/mobile networking environments that use Qualcomm RMNET functionality. Current EPSS is very low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is not indicated; however, kernel flaws should still be prioritized where untrusted local users, containers with elevated networking capabilities, or device-management interfaces can exercise RMNET link operations.

How an attack unfolds

An attacker first needs local execution or another mechanism that can interact with the kernel networking stack and RMNET interfaces. They create or manipulate RMNET virtual network devices, then trigger deletion of an RMNET link while concurrently sending or injecting packets through the receive path. The vulnerable deletion path removes the RMNET endpoint from the hash table and frees it before all RCU readers are guaranteed to be finished. A racing receive handler may still hold a stale reference and dereference the freed endpoint's egress_dev pointer. In a straightforward attack, this causes a kernel page fault and system crash. More advanced exploitation would require carefully shaping kernel heap reuse after the free so the stale pointer dereference operates on attacker-influenced memory, but no active exploitation or public weaponization is currently known from the provided data.

How to fix it

Apply the Linux kernel update that includes the RMNET fix replacing immediate endpoint free with RCU-safe freeing and avoiding the egress_dev data race during the grace period. Because no product-specific fixed versions were provided, track the fix through the relevant upstream stable kernel branch, Linux distribution kernel advisory, Android/vendor BSP release, or device firmware update. If immediate patching is not possible, reduce exposure by disabling or unloading the RMNET driver where it is not required, preventing untrusted users or containers from creating/manipulating network devices, restricting CAP_NET_ADMIN, limiting access to tun/tap devices, and applying standard hardening such as kernel lockdown, module-loading restrictions, and container capability minimization.

How to confirm the fix worked

Confirm the running kernel includes the RMNET patch by checking the distribution/vendor kernel changelog or source package for the change that adds RCU-delayed freeing of struct rmnet_endpoint, such as use of kfree_rcu() in the RMNET endpoint deletion path. Verify the deployed kernel version matches the vendor advisory containing the fix and reboot into the patched kernel. Where source validation is possible, inspect net/qualcomm/rmnet code for the corrected rmnet_dellink() behavior. To assess exposure, verify whether the RMNET driver is present or loaded, whether RMNET interfaces exist, and whether untrusted principals have CAP_NET_ADMIN or access to mechanisms that can create/delete network devices. After remediation, stress-test RMNET link deletion and packet ingress in a non-production environment and confirm no kernel oops occurs in rmnet_vnd_rx_fixup, __rmnet_map_ingress_handler, or rmnet_rx_handler.

Typical attack path

1. Obtain local code execution or sufficient privileges/capabilities to manipulate network interfaces or RMNET configuration.
2. Create or configure RMNET virtual network devices on a kernel with the affected Qualcomm RMNET driver code.
3. Start traffic generation through the RMNET receive path, potentially using tun/tap or another packet injection mechanism.
4. Concurrently delete the RMNET link to trigger rmnet_dellink() while receive-path RCU readers are active.
5. Win the race so the receive handler dereferences an endpoint after it has been freed.
6. Cause a kernel oops/panic and denial of service, or attempt further exploitation by influencing kernel heap reuse.

How to detect it

Look for evidence of kernel crashes, oops reports, panics, or KASAN/use-after-free findings involving the RMNET driver. Relevant log sources include journald, syslog, dmesg, kernel crash dumps, pstore/ramoops, kdump/vmcore artifacts, Android logcat/kernel logs on mobile or embedded devices, and endpoint telemetry that captures kernel fault events. Search for stack traces containing rmnet_dellink, rmnet_vnd_rx_fixup, __rmnet_map_ingress_handler, rmnet_rx_handler, tun_get_user, or tun_chr_write_iter. Correlate crashes with recent creation/deletion of RMNET interfaces, rtnetlink activity, ip link operations, changes in network namespaces, tun/tap writes, or processes with CAP_NET_ADMIN. Since the most likely observable result is denial of service rather than a durable userland artifact, absence of file or process indicators does not rule out attempted exploitation. Preserve vmcore or pstore data when RMNET-related crashes occur and inspect whether the faulting instruction dereferenced a freed endpoint or an invalid egress_dev pointer.

• BUG: unable to handle page fault
• Oops: 0002
• RIP: 0010:rmnet_vnd_rx_fixup
• rmnet_vnd_rx_fixup
• __rmnet_map_ingress_handler
• rmnet_rx_handler
• rmnet_dellink
• tun_get_user
• tun_chr_write_iter
• KASAN: use-after-free
• use-after-free in rmnet
• net: qualcomm: rmnet
• egress_dev
• struct rmnet_endpoint
• /sys/module/rmnet
• /proc/modules

What your security team should do

• Inventory Linux, Android-derived, embedded, and telecom/mobile systems that include or load the Qualcomm RMNET driver.
• Prioritize patching systems where RMNET is used and where untrusted local users, containers, or management agents can manipulate network interfaces.
• Update to the vendor kernel, firmware, or distribution release that contains the RMNET RCU use-after-free fix, then reboot to ensure the fixed kernel is active.
• If patching is delayed, disable RMNET where unnecessary and restrict CAP_NET_ADMIN, tun/tap access, module loading, and network namespace creation for untrusted workloads.
• Monitor kernel logs for crashes or warnings in RMNET receive/delete paths, especially rmnet_vnd_rx_fixup, __rmnet_map_ingress_handler, rmnet_rx_handler, and rmnet_dellink.
• Treat unexplained kernel oops or panic events involving RMNET as potential exploitation or reliability-triggered security events and preserve crash dumps for analysis.
• Because the issue is not currently KEV-listed and has low EPSS, handle it through normal kernel patch SLAs unless RMNET is exposed to untrusted local actors or supports critical availability-sensitive services.