CVE-2023-33063

What it actually does

This is a use-after-free memory corruption vulnerability in DSP Services triggered during a remote procedure call from the High-Level Operating System to the DSP. A local, low-privileged attacker can cause DSP service code to access memory after it has been freed, potentially corrupting memory in a controlled way. Successful exploitation can lead to arbitrary code execution, privilege escalation, disclosure or modification of sensitive data processed by the DSP, and denial of service. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems or devices using affected Qualcomm chipset software or downstream affected builds may be exposed to local privilege escalation and full device compromise after an attacker first obtains low-privileged code execution. Because this vulnerability is listed in CISA KEV and has active in-the-wild exploitation, it should be treated as an operationally urgent issue even though EPSS is currently low. Impact can include service disruption, compromise of mobile, embedded, telecom, or edge devices, exposure of protected data, persistence below normal application layers, and increased incident response difficulty. The CISA KEV remediation due date was 2023-12-26, so any remaining exposure is overdue.

How an attack unfolds

An attacker typically needs an initial foothold that allows local code execution with low privileges, such as a malicious app, compromised service, abused debug interface, or chained vulnerability. From that foothold, the attacker opens or reaches the DSP communication interface and sends crafted remote-call data from the HLOS side to DSP Services. The malformed call causes an object or buffer lifecycle error where freed memory is later reused. By shaping heap state and call timing, the attacker attempts to turn the memory corruption into controlled execution or data manipulation in the DSP service context. If successful, the attacker can escalate privileges, tamper with DSP-handled workloads, destabilize the device, or chain the access with other platform weaknesses to affect the broader operating system. Public reporting and KEV status indicate active exploitation against Qualcomm multiple-chipset environments, so defenders should assume real-world exploit chains may be more reliable than proof-of-concept-only activity.

How to fix it

Apply vendor-provided security updates for all affected Qualcomm chipset firmware, BSPs, device images, and downstream products. For environments building from the listed affected source, update open5gs/open5gs Git deployments to commit 426fa3f84a0cb332e9971ad9408935838cf98fa6 or a later release that contains that fix. Validate that OEM, carrier, embedded-device, and appliance firmware images include the corrected DSP Services components, not only application-layer packages. Where immediate patching is not possible, reduce exposure by restricting local access to DSP/FastRPC device interfaces, enforcing SELinux/AppArmor or equivalent mandatory access controls, disabling unnecessary debug interfaces, preventing untrusted local code execution, limiting sideloading, and monitoring for abnormal crashes or DSP subsystem resets. Because this issue is in CISA KEV and exploitation is active in the wild, prioritize remediation ahead of routine patch cycles.

How to confirm the fix worked

Confirm installed firmware, BSP, kernel/vendor modules, and downstream product versions are at or above the vendor-fixed level. For source-based deployments, verify the repository contains commit 426fa3f84a0cb332e9971ad9408935838cf98fa6 or a later commit, and rebuild/redeploy all binaries derived from the vulnerable code. On managed devices, validate security patch level or OEM advisory mapping for the Qualcomm chipset family. Check that access controls on DSP-related device nodes are restricted to expected trusted processes and that untrusted applications cannot directly access DSP remote-call interfaces. Perform a controlled reboot and health check after patching to ensure DSP services initialize normally. Review crash telemetry and kernel/system logs before and after remediation to confirm that recurring DSP, FastRPC, ADSP, CDSP, or subsystem restart errors have ceased.

Typical attack path

1. Gain local low-privileged execution on an affected device or system through a malicious application, compromised process, physical/debug access, or another vulnerability.
2. Identify that the target uses an affected Qualcomm DSP Services implementation or a downstream component built from vulnerable source.
3. Interact with the HLOS-to-DSP remote-call interface exposed to user space or a reachable local service.
4. Send crafted remote-call parameters that trigger the use-after-free condition in DSP Services.
5. Manipulate memory layout so the stale freed object is reused in an attacker-influenced way.
6. Achieve memory corruption leading to code execution, privilege escalation, sensitive data access, or device crash.
7. Use the elevated access to persist, disable security controls, access protected data, or continue lateral/chained exploitation.

How to detect it

Look for evidence of local exploit chaining rather than a single definitive network indicator, because exploitation is local and occurs through HLOS-to-DSP calls. Useful sources include kernel logs, Android logcat where applicable, DSP subsystem logs, FastRPC/ADSP/CDSP driver logs, crash dump directories, EDR process telemetry, mobile threat defense telemetry, audit logs for device-node access, SELinux/AppArmor denials, package installation history, and firmware integrity measurements. Investigate repeated DSP subsystem restarts, unexplained crashes in DSP-related services, abnormal access to FastRPC or DSP device nodes by nonstandard applications, newly installed or sideloaded apps shortly before DSP crashes, privilege transitions following DSP errors, and attempts to disable logging or security controls. In Qualcomm environments, correlate log entries containing DSP, ADSP, CDSP, FastRPC, or adsprpc errors with process execution and package-install events. For KEV-driven hunting, review historical telemetry from at least the publication date, 2023-12-05, and prioritize devices that were unpatched after the 2023-12-26 KEV deadline.

• adsprpc
• fastrpc
• FastRPC
• ADSP
• CDSP
• DSP Services
• subsystem_restart
• SSR:
• remote_handle_invoke
• /dev/adsprpc-smd
• /dev/adsprpc-smd-secure
• /dev/fastrpc-adsp
• /dev/fastrpc-cdsp
• /dev/fastrpc-mdsp
• /dev/fastrpc-sdsp
• avc: denied
• type=1400

What your security team should do

• Immediately inventory devices, appliances, embedded systems, mobile endpoints, and telecom/edge components using affected Qualcomm chipsets or downstream affected builds.
• Prioritize patching because the vulnerability is CISA KEV-listed, actively exploited in the wild, and the federal remediation due date of 2023-12-26 has passed.
• Update open5gs/open5gs Git-based builds to commit 426fa3f84a0cb332e9971ad9408935838cf98fa6 or later where that affected product is present.
• Coordinate with OEMs, carriers, chipset vendors, and appliance suppliers to obtain firmware images that explicitly include the DSP Services fix.
• Hunt for abnormal local privilege escalation activity, unexpected DSP/FastRPC access, repeated DSP subsystem crashes, and suspicious applications or binaries interacting with DSP device interfaces.
• Restrict local code execution paths, sideloading, debug shells, and direct access to DSP-related device nodes until patching is complete.
• Preserve kernel logs, Android logcat output where applicable, crash dumps, and EDR telemetry for devices showing DSP crashes or unexplained privilege changes.
• Treat exploitation as a potential chained compromise and investigate for follow-on persistence, credential theft, tampering with security controls, and data access.