CVE-2026-53159

What it actually does

This vulnerability affects the Linux kernel FastRPC driver, commonly used on Qualcomm-based systems to communicate with DSP components. The flaw occurs when the kernel attempts to translate a user-supplied pointer into a DMA address. The vulnerable code used find_vma(), which may return the next virtual memory area even when the supplied address is not actually inside that mapping. If the pointer falls in an unmapped gap before the returned VMA, an offset calculation can underflow, producing a corrupted DMA address that is then passed to the DSP. At a technical level, this can cause invalid DMA operations, memory corruption, device instability, DSP faults, or kernel crashes. Exploitation appears to require local access to an affected system and the ability to reach the FastRPC interface; no public exploit maturity is currently indicated and EPSS is low.

Why it matters to the business

Successful exploitation could disrupt affected Linux-based systems by crashing the kernel, destabilizing DSP-dependent services, or causing device malfunction. Systems that rely on Qualcomm DSP acceleration for audio, video, AI/ML, modem-adjacent processing, or embedded workloads may experience degraded service or outages. The currently reported exploitation likelihood is low, it is not known to be in CISA KEV, and it is not known to be used in ransomware campaigns, but kernel memory-corruption flaws should still be prioritized for routine patching because they affect system stability and may become more valuable if exploit techniques mature.

How an attack unfolds

An attacker first needs local code execution or the ability to invoke the affected FastRPC device interface on a vulnerable Linux kernel. The attacker supplies a crafted pointer as part of a FastRPC argument. Instead of confirming that the pointer is contained inside a valid virtual memory area, the vulnerable kernel code may select the next VMA when the address lies in an unmapped gap. The driver then computes a DMA offset using that incorrect VMA. Because the pointer address is lower than the VMA start, the subtraction underflows and creates a bogus DMA address. That corrupted DMA address is sent to the DSP, which may attempt invalid memory access or otherwise process corrupted mapping information. The expected outcomes include kernel warnings, DSP subsystem faults, process termination, device instability, or denial of service; stronger impact such as controlled memory corruption depends on platform-specific FastRPC behavior, memory layout, DMA protections, and device configuration.

How to fix it

Apply the Linux kernel update that replaces the incorrect find_vma() usage with vma_lookup() in the FastRPC argument handling path. Because no product-specific fixed versions were provided, use the fixed kernel supplied by the relevant Linux distribution, Android/device vendor, embedded platform vendor, or kernel maintainer. Prioritize systems that include Qualcomm FastRPC support or expose FastRPC device nodes to local applications. Where immediate patching is not possible, reduce exposure by limiting local shell/application access, restricting permissions to FastRPC device nodes where operationally feasible, disabling unused FastRPC/DSP functionality, and using standard kernel hardening controls such as SELinux/AppArmor confinement and least-privilege device access policies. Mitigations should be treated as temporary; the durable fix is the corrected kernel code.

How to confirm the fix worked

Confirm that the running kernel includes the upstream or vendor patch changing the FastRPC VMA lookup behavior from find_vma() to vma_lookup() in the vulnerable argument path. Validate by checking the installed kernel package version against the vendor advisory or kernel changelog for this fix. On source-based or embedded builds, inspect the FastRPC driver code and confirm that user pointers are accepted only when vma_lookup() returns a VMA containing the address. Confirm whether FastRPC is present by checking for the relevant kernel configuration, loaded modules, device tree/platform support, and exposed FastRPC device nodes. After patching, reboot into the fixed kernel and verify that the running kernel version matches the patched package, not just that the package is installed.

Typical attack path

1. Gain local execution on a Linux system with the affected FastRPC kernel driver present and reachable.
2. Open or otherwise interact with the FastRPC interface exposed by the system.
3. Prepare a FastRPC request containing a user-space pointer that falls in an unmapped gap immediately before a valid VMA.
4. Trigger the vulnerable argument handling path in fastrpc_get_args().
5. Cause the kernel to calculate an underflowed DMA offset because the address is not actually contained in the returned VMA.
6. Pass the corrupted DMA address to the DSP through the FastRPC mechanism.
7. Induce a DSP fault, kernel fault, device instability, or denial-of-service condition.

How to detect it

To assess possible prior exploitation, review host and device logs for FastRPC, DSP, DMA, IOMMU, and kernel fault events. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, Android logcat and tombstones where applicable, embedded platform crash logs, ramoops/pstore records, watchdog reset reports, and vendor DSP crash dumps. Look for local processes interacting with FastRPC immediately before kernel oops messages, DSP subsystem restarts, DMA/IOMMU translation faults, or unexplained reboots. Because exploitation depends on crafted runtime behavior and no public exploit indicators are available, absence of logs does not prove absence of attempted exploitation. Focus forensic review on repeated crashes involving fastrpc_get_args(), FastRPC ioctl handling, DSP memory mapping, or invalid DMA/IOMMU addresses, especially when correlated with untrusted local applications or recently introduced binaries.

• fastrpc_get_args
• fastrpc
• FastRPC
• adsprpc
• /dev/adsprpc-smd
• /dev/adsprpc-smd-secure
• /dev/fastrpc
• DMA address
• IOMMU fault
• arm-smmu
• SMMU fault
• DSP crash
• subsystem restart
• SSR
• kernel oops
• BUG: kernel NULL pointer dereference
• watchdog: watchdog0: watchdog did not stop

What your security team should do

• Identify Linux systems, embedded devices, mobile/edge platforms, and appliances using Qualcomm FastRPC or DSP offload functionality.
• Check vendor advisories and kernel package changelogs for the fix, then schedule patching through normal kernel update processes.
• Prioritize internet-managed, kiosk, shared-user, developer-accessible, mobile, edge, and embedded systems where local code execution by less-trusted users or apps is plausible.
• Restrict access to FastRPC device nodes to only trusted services and users until patched.
• Review SELinux, AppArmor, udev, container, and sandbox policies to ensure untrusted workloads cannot directly access FastRPC interfaces.
• Monitor for unexplained DSP crashes, kernel oops events, device resets, and FastRPC-related errors as possible signs of attempted triggering.
• For embedded or vendor-managed platforms, request a patched firmware or BSP release if standard Linux kernel packages are not used.
• Treat this as a stability and local attack-surface issue rather than an urgent internet-facing remote exploitation issue unless new exploit evidence emerges.