CVE-2026-43204

What it actually does

CVE-2026-43204 is a local denial-of-service flaw in the Linux kernel Qualcomm ASoC q6asm audio path. The bug occurs when Qualcomm DSP responses associated with a data stream continue to be processed after that stream has already been closed. Instead of being discarded, stale asynchronous DSP responses can be handled against closed stream state, which can trigger kernel-level lockups. The impact is availability loss only: the CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, unchanged scope, no confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems using the vulnerable Qualcomm audio/DSP driver path to hang or become unavailable, potentially requiring a reboot and interrupting device, workstation, embedded, or mobile/IoT operations. Because exploitation requires local low-privileged access and there is no known public exploit, KEV listing, ransomware association, or meaningful EPSS increase, broad internet-scale exploitation is unlikely; however, the operational impact may be significant for products or fleets that rely on Qualcomm-based Linux kernels where local users, apps, containers, or untrusted workloads can access audio/DSP interfaces.

How an attack unfolds

An attacker first needs local code execution or an existing low-privileged account on a system running an affected Linux kernel with the Qualcomm ASoC q6asm driver path in use. The attacker then interacts with audio/DSP stream interfaces in a way that opens a data stream, closes it, and causes or races delayed DSP responses to arrive after closure. In the vulnerable kernel, those late responses are still processed rather than dropped. Processing stale responses for a closed stream can lead to kernel lockup, resulting in a denial of service. There is no indication from the provided data that this vulnerability enables privilege escalation, data theft, remote code execution, or ransomware deployment.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or upstream kernel branch that includes the q6asm fix to unconditionally drop DSP responses associated with closed data streams. No exact fixed package versions were provided, so organizations should track vendor advisories for their kernel build, especially for Qualcomm-based Linux devices and downstream BSP kernels. Where immediate patching is not possible, reduce exposure by limiting local shell/app access to trusted users, restricting access to audio/DSP device nodes where operationally feasible, disabling unused Qualcomm audio/DSP functionality, and prioritizing reboot-capable operational safeguards for affected embedded or endpoint fleets.

How to confirm the fix worked

Confirm the running kernel includes the q6asm patch that drops DSP responses for closed data streams, either by verifying the vendor advisory/package changelog or checking that the relevant upstream fix is present in the kernel source used for the build. Inventory systems for Qualcomm ASoC/q6asm support and confirm patched kernel versions are actually booted, not merely installed. Functional validation should include opening and closing audio/DSP streams under stress while monitoring for kernel warnings, stalls, soft lockups, hard lockups, or device hangs. Exposure is most relevant where local users or applications can interact with Qualcomm DSP-backed audio interfaces.

Typical attack path

1. Obtain local low-privileged execution on an affected Linux system using the vulnerable Qualcomm ASoC q6asm audio/DSP driver path.
2. Access audio/DSP functionality exposed to local users or applications.
3. Create and close q6asm-backed audio data streams repeatedly or under timing conditions that produce delayed DSP responses.
4. Trigger handling of DSP responses after the associated stream has already been closed.
5. Cause the vulnerable kernel path to lock up, degrading or stopping system availability until recovery or reboot.

How to detect it

Detection should focus on evidence of denial-of-service behavior rather than compromise, because the vulnerability does not provide a known file, network, credential, or persistence artifact. Review kernel logs, system journal entries, console logs, watchdog logs, crash dumps, and device management telemetry for lockups or hangs occurring around Qualcomm audio/DSP activity. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, pstore/ramoops records, kdump/vmcore analysis, watchdog reset reasons, and mobile/embedded device diagnostic logs. Look for repeated local processes opening and closing audio devices shortly before kernel stalls, audio subsystem errors involving q6asm/q6audio/ADSP/APR, and soft-lockup or hard-lockup messages. Because no public exploit maturity, KEV status, ransomware use, or named threat actor activity is provided, confirmed exploitation generally requires correlating suspicious local process activity with the timing of kernel lockups on an affected, unpatched kernel.

• q6asm
• ASoC: qcom
• qcom,q6asm
• DSP response
• closed data stream
• soft lockup
• hard LOCKUP
• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• rcu: INFO: rcu_sched self-detected stall
• rcu: INFO: rcu_preempt detected stalls
• kernel panic - not syncing
• pstore
• ramoops
• /sys/fs/pstore/
• /proc/device-tree/soc
• /dev/snd/
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching affected Qualcomm-based Linux kernels in environments where untrusted local users, apps, containers, or third-party workloads can access audio/DSP interfaces.
• Ask OS, device, and BSP vendors for the kernel version or patch level that contains the q6asm closed-stream DSP response fix, since no exact fixed versions were provided.
• Inventory Linux assets for Qualcomm ASoC/q6asm driver usage and separate truly affected devices from generic Linux systems that do not include or load this driver path.
• Review permissions on audio/DSP device nodes and restrict access to trusted users or services where feasible until patched.
• Monitor affected systems for kernel lockup messages, unexpected reboots, watchdog resets, and audio/DSP driver errors that may indicate attempted or accidental triggering.
• Treat this as a local availability risk rather than a remote compromise risk unless combined with another vulnerability that grants local execution.