CVE-2026-46157

What it actually does

This is a local Linux kernel race condition in the ALSA PCM OSS compatibility layer. The runtime.oss.trigger bit field can be read and written concurrently without the existing params_lock mutex in snd_pcm_oss_get_trigger() and snd_pcm_oss_poll(). Because the affected value is a bit field, an unsynchronized write can corrupt neighboring bit fields in the same storage unit, potentially causing incorrect audio subsystem state, kernel memory corruption, crashes, or privilege-impacting behavior. The CVSS vector indicates local access with low attack complexity and low privileges, with potential high confidentiality, integrity, and availability impact.

Why it matters to the business

A user or process with local access to an affected Linux system may be able to crash the system or potentially escalate privileges through the kernel. The risk is highest on multi-user Linux systems, developer workstations, desktop fleets, audio-enabled servers, container hosts that expose audio devices, and systems where untrusted users or sandboxed workloads can access OSS/ALSA audio interfaces. This is not listed in CISA KEV, has no known ransomware association, and currently has low EPSS, but kernel local privilege escalation issues should still be prioritized where untrusted local code execution is possible.

How an attack unfolds

An attacker first needs the ability to run code locally on an affected Linux system. They then interact with the ALSA OSS PCM compatibility interface, typically through OSS-style audio device operations such as open, poll, ioctl, or trigger-related access patterns. By creating concurrent threads that repeatedly exercise the relevant PCM OSS paths, the attacker attempts to win the race between readers and writers of runtime.oss.trigger. If the race is hit, adjacent bit fields may be overwritten or inconsistent kernel state may be produced. Depending on kernel configuration, timing, and memory layout, this may result in denial of service through a kernel crash, corruption of ALSA PCM runtime state, or a path toward local privilege escalation. No public exploit maturity is reported in the supplied data, so exploitation should be treated as plausible but not confirmed in the wild.

How to fix it

Apply vendor-supplied Linux kernel updates that include the ALSA PCM OSS locking fix for runtime.oss.trigger. Because no exact fixed package versions were provided, track the advisory and kernel packages from the operating system or appliance vendor rather than relying only on upstream kernel version names. Reboot into the patched kernel after installation and remove older vulnerable kernels from boot preference where appropriate. As interim mitigation, restrict local shell access to trusted users, prevent untrusted workloads from accessing audio devices, disable or avoid loading OSS PCM compatibility modules where not needed, and ensure device permissions for /dev/dsp, /dev/audio, /dev/snd/*, and related audio interfaces are not exposed to untrusted users or containers.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that includes the ALSA PCM OSS params_lock fix in snd_pcm_oss_get_trigger() and snd_pcm_oss_poll(). Validate by checking the active kernel version after reboot with uname -r and comparing the installed package changelog or vendor advisory for the CVE or the ALSA PCM OSS trigger locking fix. Where source validation is possible, confirm accesses to runtime.oss.trigger in the affected OSS PCM paths are protected by params_lock. Also verify whether OSS compatibility is enabled or loaded, review permissions on audio device nodes, and confirm untrusted containers or users cannot access host audio devices unless explicitly required.

Typical attack path

1. Obtain local code execution as a low-privileged user or compromised process on an affected Linux host.
2. Verify that ALSA PCM OSS compatibility is available and that OSS-style audio device access is permitted.
3. Open and manipulate OSS/ALSA PCM audio devices from multiple threads or processes.
4. Repeatedly trigger concurrent poll and trigger-state operations to race access to runtime.oss.trigger.
5. Cause corrupted PCM runtime state, adjacent bit-field overwrite, or kernel instability.
6. Leverage the resulting condition for denial of service or attempt further kernel exploitation for privilege escalation.

How to detect it

Look for evidence of local processes repeatedly accessing OSS or ALSA audio devices shortly before kernel instability, crashes, or sanitizer reports. Relevant sources include systemd journal, /var/log/kern.log, /var/log/messages, auditd logs, eBPF/EDR telemetry, process execution records, and container runtime logs for device passthrough. Search for kernel messages referencing snd_pcm_oss, ALSA PCM OSS, data races, KCSAN reports, BUG/Oops/panic events, general protection faults, or lockless access around audio subsystem activity. In audit logs, review open, ioctl, and poll-heavy activity against /dev/dsp, /dev/audio, /dev/mixer, and /dev/snd/* by unexpected users, services, containers, or recently introduced binaries. Because no public exploit indicators or actor-specific artifacts are provided, detection should focus on behavioral correlation: suspicious local audio-device access followed by kernel warnings, crashes, or privilege anomalies.

• snd_pcm_oss
• runtime.oss.trigger
• KCSAN: data-race
• ALSA: pcm: oss
• /dev/dsp
• /dev/audio
• /dev/mixer
• /dev/snd/
• snd-pcm-oss
• snd_pcm_oss_get_trigger
• snd_pcm_oss_poll
• BUG: kernel NULL pointer dereference
• Oops:
• kernel panic
• general protection fault

What your security team should do

• Prioritize patching systems that allow untrusted local users, shared development environments, VDI/workstations, lab machines, and container hosts with exposed audio devices.
• Inventory Linux hosts with ALSA OSS compatibility enabled or loaded, especially systems exposing /dev/dsp, /dev/audio, or /dev/snd/* to users or containers.
• Apply the relevant vendor kernel update and reboot into the fixed kernel; confirm the active kernel is patched, not just installed.
• Restrict access to audio device nodes and remove audio device passthrough from containers or sandboxes unless operationally required.
• Disable or prevent loading OSS PCM compatibility modules where not needed as a temporary risk-reduction measure.
• Monitor kernel logs for ALSA, snd_pcm_oss, KCSAN, BUG, Oops, panic, or general protection fault messages that coincide with local audio-device activity.
• Treat unexplained kernel crashes on affected systems as potentially security relevant until patched and reviewed.