CVE-2026-43412

What it actually does

This is a Linux kernel availability flaw in the Qualcomm ASoC QDSP6 audio stack, specifically the q6apm component removal path during ADSP stop/start handling. The vulnerable logic removes audio topology and PCM runtimes before dependent DAI components are fully detached, leaving stale component references linked to the sound card. On the next ADSP rebind or restart sequence, the kernel can dereference invalid or NULL state and trigger an oops/panic. The practical technical effect is a local denial of service: a user or process with sufficient local ability to trigger the affected audio/ADSP restart path can crash the kernel or destabilize the device. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact with no direct confidentiality or integrity impact.

Why it matters to the business

Affected Linux systems using Qualcomm QDSP6/ADSP audio components may experience unexpected crashes, reboots, or service interruptions. This is most relevant for embedded Linux, mobile, automotive, edge, and development platforms built on Qualcomm SoCs where audio DSP restart or subsystem recovery paths are reachable. Although there is no evidence of known exploitation and EPSS is very low, the impact can still be operationally significant for systems that require continuous uptime, physical access resilience, or reliable media/audio services. Because publication was 95 days ago, organizations maintaining custom kernels or vendor BSPs should verify whether the upstream fix has been incorporated into their kernel branch.

How an attack unfolds

An attacker first needs local access to an affected Linux system and enough privileges or device access to interact with the relevant Qualcomm audio/ADSP subsystem paths. The attacker then causes or waits for an ADSP stop/start or subsystem restart condition that exercises the q6apm-audio removal and rebind sequence. In a vulnerable kernel, ASoC teardown removes topology and PCM runtime structures before all dependent q6apm DAI components are detached. This leaves stale component links attached to the sound card. When the ADSP is started again and the audio stack is rebound, the kernel follows one of those invalid references and faults, commonly producing a NULL pointer dereference in the ASoC shutdown path. Successful exploitation results in a kernel oops, panic, reboot, or persistent instability until the patched kernel behavior is applied. There is no indication from the provided intelligence that this vulnerability is being exploited by named threat actors, ransomware campaigns, or public exploit tooling.

How to fix it

Apply a Linux kernel build that includes the upstream fix for the Qualcomm ASoC qdsp6 q6apm removal-ordering issue. No exact fixed version was provided in the input, so remediation should be based on the relevant distribution, vendor BSP, or upstream stable kernel advisory once the patch has been backported. For custom kernels, review the ASoC Qualcomm qdsp6/q6apm changes that ensure dependent child components are removed before the parent q6apm component, and that q6apm is removed last during ADSP stop/start teardown. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to audio and DSP device nodes, disabling unneeded Qualcomm audio/ADSP functionality where operationally acceptable, and preventing untrusted users or containers from interacting with host audio devices. Embedded and appliance vendors should incorporate the fix into firmware images and validate ADSP restart/recovery scenarios before release.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes Qualcomm QDSP6/ADSP ASoC components and whether the kernel source or package contains the corrected q6apm removal ordering. On running systems, inspect loaded modules and platform configuration for q6apm, snd_q6apm, q6apm_dai, q6apm_lpass_dais, snd_q6dsp_common, qcom_q6v5_pas, pdr_interface, qrtr, apr, or related Qualcomm ADSP/audio components. Validate remediation in a non-production test environment by exercising ADSP stop/start, subsystem restart, audio card unbind/rebind, suspend/resume, and audio playback/capture teardown paths while monitoring dmesg or journald for kernel oops output. A fixed system should not produce NULL pointer dereferences, ASoC teardown crashes, or pdr_notifier_work-related kernel faults during repeated ADSP restart cycles. For packaged kernels, verify the installed kernel version or vendor changelog explicitly includes the CVE fix or the corresponding upstream patch.

Typical attack path

1. Gain local access to a Linux system using the affected Qualcomm QDSP6/ADSP ASoC audio driver stack.
2. Confirm the vulnerable Qualcomm audio modules and device topology are present, such as q6apm, q6apm_dai, q6apm_lpass_dais, snd_q6apm, or related qdsp6 components.
3. Trigger an ADSP stop/start, subsystem recovery, driver unbind/rebind, device reset, or other path that causes ASoC component teardown and reinitialization.
4. Cause the vulnerable q6apm-audio removal sequence to delete PCM runtimes and topology before dependent DAI components are removed.
5. Wait for the next rebind/start sequence to dereference stale or NULL component state.
6. Observe a kernel oops, panic, reboot, or loss of service, resulting in local denial of service.

How to detect it

Because this vulnerability causes a denial-of-service crash rather than a clear persistence or code-execution artifact, detection should focus on kernel crash evidence and repeated triggering patterns. Review kernel logs from journald, dmesg, persistent pstore/ramoops, crash dumps, and device telemetry for NULL pointer dereferences or kernel oops events involving Qualcomm ASoC qdsp6/q6apm components during ADSP stop/start or subsystem recovery. Useful log sources include /var/log/kern.log, /var/log/messages, journalctl -k output, /sys/fs/pstore/*, kdump/vmcore analysis, and embedded device crash-reporting stores. Look for faults in or near mutex_lock, soc_dapm_shutdown_dapm, q6apm-audio removal, pdr_notifier_work, pdr_interface, snd_soc_core, snd_q6apm, q6apm_dai, and q6apm_lpass_dais. Correlate crashes with local user sessions, application launches, audio device access, driver unbind/rebind operations, subsystem restarts, suspend/resume events, or container workloads that have host audio device access. A single crash may be ordinary driver instability, but repeated crashes with similar stack traces following ADSP restart activity should be investigated as possible exploitation or deliberate denial-of-service testing.

• Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
• Internal error: Oops: 0000000096000004
• pc : mutex_lock+0xc/0x54
• lr : soc_dapm_shutdown_dapm
• Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface]
• q6apm-audio
• q6apm_lpass_dais
• q6apm_dai
• snd_q6dsp_common
• snd_q6apm
• q6prm_clocks
• q6prm
• pdr_interface
• qcom_q6v5_pas
• snd_soc_core
• ASoC: qcom: qdsp6
• ADSP stop
• ADSP start
• Data abort info:
• FSC = 0x04: level 0 translation fault
• Modules linked in: q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm

What your security team should do

• Inventory Linux systems and firmware images using Qualcomm SoCs with QDSP6/ADSP audio support, prioritizing embedded, edge, automotive, mobile, and appliance deployments.
• Determine whether the running kernel or vendor BSP contains the q6apm/ASoC removal-ordering fix; if uncertain, request confirmation from the OS, silicon, device, or BSP vendor.
• Patch or upgrade affected kernels through the appropriate distribution or device firmware update channel, prioritizing systems where untrusted local users, applications, containers, or physical users can access audio/DSP functionality.
• For custom kernel programs, backport the upstream fix and regression-test ADSP restart, subsystem recovery, suspend/resume, and audio device rebind scenarios.
• Restrict access to audio and DSP device nodes for untrusted users and containers until patching is complete.
• Monitor kernel logs for ASoC/q6apm crashes, ADSP restart loops, pdr_notifier_work faults, and NULL pointer dereferences that match the vulnerable failure mode.
• Treat repeated local kernel crashes on affected Qualcomm platforms as potential abuse until hardware instability, driver defects, and intentional triggering have been ruled out.