CVE-2026-53160

What it actually does

This is a Linux kernel use-after-free race in the Qualcomm FastRPC misc driver. The vulnerable path returns a raw FastRPC map pointer after releasing the FastRPC file lock, then attempts to take a reference on that pointer outside the lock. A concurrent memory unmap operation can free the same map object in the gap between lock release and reference acquisition, causing subsequent code to operate on a freed slab object. Depending on kernel configuration, memory layout, device exposure, and exploit reliability, the impact can range from kernel crash and denial of service to potential local privilege escalation through controlled reuse of the freed kernel object.

Why it matters to the business

Systems using affected Linux kernels with the FastRPC driver enabled may be vulnerable to local crashes or privilege escalation by an attacker who already has the ability to interact with the FastRPC device interface. This is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, the risk is higher for Android, embedded, edge, or Linux-based products using Qualcomm DSP/FastRPC functionality where untrusted apps or local users can access the driver.

How an attack unfolds

An attacker first needs local code execution or an application context that can open and issue ioctls to the FastRPC device interface. The attacker then creates or looks up a FastRPC memory map while concurrently triggering a MEM_UNMAP operation against the same map. By repeatedly racing these operations, the attacker attempts to cause the kernel to release the FastRPC file lock, free the map object, and then execute the reference-taking path on the stale pointer. A simple exploit may produce a kernel oops or panic, causing denial of service. A more advanced exploit would attempt to reclaim the freed slab allocation with attacker-influenced data before the stale pointer is used, potentially converting the use-after-free into kernel memory corruption and privilege escalation.

How to fix it

Update to a Linux kernel build that includes the fix restoring atomic reference acquisition under the FastRPC file lock in fastrpc_map_lookup. If vendor fixed versions are not yet published for the affected platform, obtain the latest kernel or device firmware/security update from the operating system, distribution, hardware vendor, or Android device vendor. Where immediate patching is not possible, reduce exposure by disabling the FastRPC driver if it is not required, preventing untrusted users or applications from accessing FastRPC device nodes, tightening udev/SELinux/AppArmor policies, and restricting containers or sandboxed workloads from passing through FastRPC devices.

How to confirm the fix worked

Confirm that the running kernel contains the patched FastRPC implementation where the map reference is acquired atomically while the FastRPC lock is held. Validate by checking the vendor kernel changelog, package advisory, kernel source, or device firmware release notes for the FastRPC use-after-free race fix. On Linux systems, inventory loaded modules and device nodes to determine whether FastRPC is exposed, for example by checking for FastRPC-related modules, kernel config options, and /dev FastRPC nodes. After patching, verify the active running kernel or firmware version, not only the installed package version, and reboot if required for the new kernel to take effect.

Typical attack path

1. Gain local code execution on a system where the FastRPC driver is present and accessible.
2. Open the FastRPC device interface, commonly exposed through Qualcomm DSP/FastRPC device nodes on supported platforms.
3. Create or reference a FastRPC memory mapping through the driver interface.
4. Concurrently issue a memory unmap operation for the same mapping while another thread triggers the vulnerable map lookup/create path.
5. Win the race so the map object is freed after lookup but before the reference is safely acquired.
6. Trigger use of the stale pointer, causing a kernel crash or attempting controlled slab reuse for privilege escalation.

How to detect it

Look for evidence in kernel logs, crash dumps, pstore/ramoops records, Android tombstones, audit logs, and endpoint telemetry showing FastRPC activity immediately before a kernel oops, panic, KASAN report, or slab use-after-free warning. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, pstore console logs, Android logcat kernel buffers, and EDR process telemetry for repeated attempts to open FastRPC device nodes. Since exploitation is race-based and may leave no durable file artifact, detection should focus on anomalous local access to FastRPC devices, repeated ioctl-heavy behavior, and kernel memory-corruption diagnostics referencing fastrpc_map_create, fastrpc_map_lookup, fastrpc_map_get, or MEM_UNMAP. If a crash dump is available, review call stacks for FastRPC map handling and check whether the triggering process had a legitimate reason to access DSP/FastRPC functionality.

• fastrpc_map_create
• fastrpc_map_lookup
• fastrpc_map_get
• MEM_UNMAP
• use-after-free in fastrpc
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• slab-use-after-free
• kernel BUG at drivers/misc/fastrpc
• drivers/misc/fastrpc
• /dev/fastrpc
• /dev/fastrpc-adsp
• /dev/fastrpc-cdsp
• /dev/fastrpc-mdsp
• /dev/fastrpc-sdsp

What your security team should do

• Prioritize patching Linux, Android, embedded, and edge devices that use Qualcomm FastRPC or expose FastRPC device nodes to local users, applications, containers, or sandboxed workloads.
• Inventory systems for FastRPC exposure, including loaded kernel modules, kernel configuration, device tree/vendor kernels, and /dev entries associated with FastRPC.
• Apply the latest vendor kernel, firmware, or OS security update containing the FastRPC race fix; reboot systems where required.
• If patching is delayed, restrict permissions on FastRPC device nodes and block access from untrusted applications, containers, and low-privilege users.
• Monitor kernel logs for FastRPC-related crashes, use-after-free diagnostics, KASAN reports, slab corruption, or repeated local process crashes interacting with FastRPC.
• Treat successful exploitation as a potential kernel compromise if evidence shows controlled memory corruption rather than a one-off crash.