CVE-2026-53161

What it actually does

This is a Linux kernel use-after-free race in the Qualcomm FastRPC driver. A fastrpc_user object can be freed when a process closes the FastRPC device file while an in-flight DSP invocation is still completing on a workqueue. The delayed cleanup path can then dereference freed memory through fastrpc_context_free(), fastrpc_buf_free(), or fastrpc_free_map(). The most likely impact is a kernel crash or device reboot; depending on allocator behavior, memory layout, device configuration, and attacker control over reclaimed memory, a local attacker with access to FastRPC device nodes may be able to attempt kernel memory corruption and privilege escalation.

Why it matters to the business

Systems using affected Linux kernels on Qualcomm-based platforms may be vulnerable to local denial of service and potentially local privilege escalation. Operationally, exploitation could cause device instability, service interruption, unexpected reboots, or compromise of workloads running on impacted edge, mobile, embedded, or ARM/Linux devices. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known public exploit maturity in the supplied data, so it should be prioritized based on exposure of FastRPC device nodes and the criticality of Qualcomm-based systems rather than treated as an active internet-scale emergency.

How an attack unfolds

An attacker first needs local ability to interact with the FastRPC character device, typically on a Qualcomm-based Linux or Android-derived system where FastRPC is enabled and accessible. The attacker opens a FastRPC device node, submits one or more DSP invocations that create FastRPC contexts and associated buffers or mappings, and then deliberately closes the file descriptor while a DSP response is still in flight. If timing aligns, fastrpc_device_release() frees the fastrpc_user object while the response callback schedules deferred context cleanup. When the workqueue later executes cleanup, it may dereference the freed fastrpc_user through buffer, mapping, or list-lock cleanup logic. A reliable exploit would repeatedly trigger this race to cause a kernel oops/reboot or attempt to shape heap reuse so the stale pointer references attacker-influenced data. No public exploitation or KEV activity is indicated by the provided intelligence.

How to fix it

Update to a Linux kernel version or vendor kernel build that includes the FastRPC fix adding reference counting for fastrpc_user and moving teardown into the kref release path. Because fixed versions were not provided in the input, use the corrected kernel from the relevant Linux distribution, Android device vendor, SoC vendor, or embedded platform maintainer. If immediate patching is not possible, reduce exposure by restricting permissions on FastRPC device nodes, limiting local shell/app access to FastRPC, disabling unused DSP/FastRPC functionality where supported, and applying mandatory access controls such as SELinux/AppArmor policies that prevent untrusted processes from opening FastRPC devices. On Android-derived systems, obtain the patched vendor kernel or security bulletin update from the device/OEM maintainer rather than relying only on userspace updates.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport that introduces kref-based lifetime management for fastrpc_user. Validate by checking kernel package changelogs, vendor advisories, git commits, or source diffs for changes around fastrpc_device_release(), fastrpc_user_free(), fastrpc_context_alloc(), and fastrpc_context_free(). Confirm that the fastrpc module or built-in driver version corresponds to the patched kernel currently booted, not merely installed on disk. For exposure validation, check whether the FastRPC driver is loaded or built in and whether device nodes such as /dev/fastrpc-* exist and are accessible to untrusted users or applications. After remediation, run standard workload regression tests involving DSP/FastRPC functionality and monitor kernel logs for absence of fastrpc_context_free or fastrpc_buf_free oops traces under stress testing.

Typical attack path

1. Gain local code execution on a Qualcomm-based Linux system where the FastRPC driver is loaded and FastRPC device nodes are accessible.
2. Open a FastRPC device file such as a DSP-specific FastRPC node.
3. Submit DSP invocations that allocate FastRPC contexts, buffers, maps, or mmaps.
4. Race closure of the file descriptor against completion of an in-flight DSP invocation.
5. Trigger fastrpc_rpmsg_callback() to schedule deferred cleanup while fastrpc_device_release() is freeing the associated user structure.
6. Cause the workqueue cleanup path to dereference freed fastrpc_user memory.
7. Use the condition to crash the kernel or, if exploit reliability is achieved, attempt local privilege escalation through kernel memory corruption.

How to detect it

Review kernel logs, persistent journal entries, Android tombstones/ramoops/pstore records, crash dump infrastructure, and endpoint telemetry for FastRPC-related kernel oops or panic traces. Focus on crashes where the call stack includes fastrpc_buf_free(), fastrpc_context_free(), fastrpc_free_map(), fastrpc_context_put_wq(), process_one_work(), or worker_thread. Correlate these crashes with local process activity opening FastRPC device nodes, repeated DSP invocation failures, unusual access to /dev/fastrpc-* by untrusted applications, or bursts of device-open/device-close activity followed by kernel instability. On Android-derived systems, review kernel logs, logcat kernel buffers, pstore/console-ramoops, and vendor crash reports. There are no network indicators for this issue because exploitation requires local interaction with the kernel driver. Absence of crash artifacts does not prove absence of attempted exploitation, because an unsuccessful race may leave little evidence beyond application errors or transient FastRPC failures.

• fastrpc_buf_free
• fastrpc_context_free
• fastrpc_context_put_wq
• fastrpc_free_map
• fastrpc_device_release
• fastrpc_rpmsg_callback
• pc : fastrpc_buf_free+0x38/0x80 [fastrpc]
• lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc]
• fastrpc_context_free+0xa8/0x1b0 [fastrpc]
• fastrpc_context_put_wq+0x78/0xa0 [fastrpc]
• process_one_work+0x180/0x450
• worker_thread+0x26c/0x388
• [fastrpc]
• /dev/fastrpc-adsp
• /dev/fastrpc-cdsp
• /dev/fastrpc-sdsp
• /dev/fastrpc-mdsp
• /dev/fastrpc-*

What your security team should do

• Inventory Qualcomm-based Linux, Android-derived, embedded, edge, and appliance systems that expose FastRPC functionality.
• Prioritize patching systems where untrusted local users, containers, applications, or third-party code can access FastRPC device nodes.
• Apply vendor kernel updates containing the FastRPC fastrpc_user reference-counting fix as soon as practical.
• Until patched, restrict permissions on /dev/fastrpc-* nodes and enforce SELinux/AppArmor policies preventing untrusted access.
• Monitor kernel logs and crash dumps for FastRPC-related oops traces, especially involving fastrpc_buf_free, fastrpc_context_free, and worker_thread.
• For high-assurance environments, treat unexplained FastRPC kernel crashes as potentially security relevant and preserve crash dumps for forensic review.
• Do not prioritize this above actively exploited KEV vulnerabilities solely on EPSS grounds, but do address it in normal kernel and device firmware update cycles.