CVE-2026-46143

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel Qualcomm ASoC audio path, specifically the q6apm-lpass-dai handling of playback graph preparation. The affected code can call the prepare path multiple times and open multiple playback graphs without first checking whether a graph is already open. Repeated opens can leak kernel memory. A local user or process with access to the relevant audio device path can repeatedly trigger the condition, consuming kernel memory and potentially causing system instability, audio subsystem failure, or a full system crash due to memory exhaustion. The flaw does not provide confidentiality or integrity impact and is not remotely exploitable under the assigned CVSS vector.

Why it matters to the business

Systems using affected Linux kernels on Qualcomm audio-capable platforms may be vulnerable to local resource-exhaustion attacks. A malicious local user, compromised application, or sandbox escape chain that can reach the audio subsystem could degrade device reliability, interrupt audio functionality, or crash the host. This is most relevant for mobile, embedded, workstation, IoT, and edge devices built on Qualcomm SoCs. The risk is moderate because exploitation requires local privileges and there is no known public exploit or CISA KEV listing, but availability impact can be high on exposed multi-user or application-hosting systems.

How an attack unfolds

An attacker first obtains local execution with sufficient permissions to interact with the affected ALSA/ASoC playback interface on a vulnerable Qualcomm-based Linux system. The attacker then repeatedly triggers audio playback preparation behavior in a way that causes the q6apm-lpass-dai driver prepare routine to run multiple times. Because the vulnerable kernel path may open a new graph each time without verifying whether the playback graph is already open, kernel memory is leaked on each iteration. By automating repeated prepare/open cycles, the attacker can increase unreclaimed kernel memory consumption until the system experiences memory pressure, audio failures, process kills by the OOM killer, or a kernel panic/reboot.

How to fix it

Update the Linux kernel to a version that includes the upstream fix for the Qualcomm q6apm-lpass-dai multiple graph-open memory leak. Because no exact fixed package versions were provided, use vendor kernel advisories for the relevant distribution, device BSP, Android/Linux board support package, or embedded platform and apply the first kernel build containing the ASoC qcom q6apm-lpass-dai fix that adds a check before opening the graph. Where immediate patching is not possible, reduce exposure by limiting local user access, restricting untrusted applications from audio device access, disabling or unloading the affected Qualcomm ASoC audio driver where operationally feasible, applying device cgroup or container restrictions to audio devices, and using mandatory access controls such as SELinux/AppArmor to prevent untrusted workloads from interacting with audio playback interfaces.

How to confirm the fix worked

Confirm the running kernel package or firmware image includes the patch for the ASoC Qualcomm q6apm-lpass-dai multiple graph-open fix. On source-based or vendor kernels, verify that the q6apm-lpass-dai prepare path checks whether the graph is already open before opening it again. On packaged systems, compare the installed kernel version and vendor security changelog against the advisory that includes the fix. Reboot into the patched kernel and confirm the active kernel with standard OS tooling. If practical in a test environment, repeatedly exercise audio playback prepare/start/stop behavior and monitor kernel memory usage, slab growth, dmesg, and OOM activity to confirm memory consumption no longer grows abnormally.

Typical attack path

1. Gain local code execution or use an existing low-privileged account on a vulnerable Qualcomm-based Linux system.
2. Confirm access to the relevant audio playback device or ALSA/ASoC interface.
3. Repeatedly invoke playback preparation/open behavior against the affected q6apm-lpass-dai path.
4. Cause multiple playback graph opens without corresponding cleanup, leaking kernel memory over time.
5. Continue triggering the leak until the host experiences memory exhaustion, audio subsystem failure, OOM killer activity, kernel instability, or crash.

How to detect it

Look for signs of local resource-exhaustion activity rather than a unique remote exploit signature. Useful sources include kernel logs, dmesg/journalctl output, syslog, audit logs for access to audio devices, endpoint telemetry showing repeated audio playback open/prepare loops, memory pressure metrics, OOM killer events, kernel panic records, and unexpected reboot data. Investigate repeated access to ALSA/ASoC playback devices followed by increasing kernel memory usage, slab growth, OOM kills, audio driver errors, or reboots. On systems with auditd or EDR, correlate processes repeatedly opening audio device nodes with subsequent memory exhaustion. There are no public threat actors or ransomware campaigns associated with this vulnerability in the provided intelligence.

• q6apm-lpass-dai
• q6apm
• snd-soc-qcom
• Out of memory: Killed process
• oom-killer
• Kernel panic
• /dev/snd/pcm
• /dev/snd/controlC
• /proc/asound

What your security team should do

• Prioritize patching Qualcomm-based Linux, Android-derived, embedded, edge, and appliance systems where untrusted local users or applications can access audio devices.
• Inventory systems running affected Linux kernels with Qualcomm ASoC/q6apm audio support and map them to vendor kernel or firmware update channels.
• Apply the vendor-provided kernel, firmware, BSP, or distribution update containing the q6apm-lpass-dai graph-open fix.
• Where patching is delayed, restrict access to audio devices for untrusted users, containers, and applications using device permissions, cgroups, SELinux/AppArmor, or equivalent controls.
• Monitor vulnerable systems for unexplained kernel memory growth, repeated audio subsystem activity, OOM killer events, kernel panics, or unexpected reboots.
• Because EPSS is very low, there is no KEV listing, and no known exploit maturity is reported, treat this as a controlled availability-risk patch rather than an emergency internet-facing exposure, unless affected systems host untrusted local workloads.