CVE-2026-80967: Linux Kernel ALSA Race Condition Vulnerability

CVE-2026-80967 Overview

CVE-2026-80967 is a race condition in the Linux kernel's Advanced Linux Sound Architecture (ALSA) pcxhr driver. The pcxhr_probe() function registers the threaded interrupt handler pcxhr_threaded_irq() before initializing the mgr->lock mutex. Because the threaded handler acquires that mutex, an interrupt firing during probe can operate on uninitialized mutex state. The upstream fix reorders initialization so manager locks are set up before request_threaded_irq() runs.

Critical Impact
A local attacker or misbehaving hardware event can trigger the threaded IRQ during probe, leading to kernel memory corruption, denial of service, or potential local privilege escalation on systems using the pcxhr sound driver.

Affected Products

Linux kernel builds containing the ALSA pcxhr driver prior to the fix commits
Distributions shipping vulnerable stable kernel branches referenced by the seven upstream commits
Systems with Digigram pcxhr-family sound hardware where the driver is loaded during boot or hotplug

Discovery Timeline

2026-09-11 - CVE-2026-80967 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-80967

Vulnerability Analysis

The defect is a probe-time race condition [CWE-362] in the ALSA pcxhr sound driver. The driver's pcxhr_probe() calls request_threaded_irq() to register pcxhr_threaded_irq() before the manager structure's mutex mgr->lock has been initialized. If the device asserts an interrupt between IRQ registration and mutex initialization, the kernel schedules the threaded handler, which then attempts to take an uninitialized mutex. Acquiring an uninitialized struct mutex produces undefined synchronization behavior and can corrupt the mutex wait list, leaving lock state inconsistent for the remainder of the driver's lifetime.

Because the attack vector is local and the impact spans confidentiality, integrity, and availability, exploitation on a vulnerable system can result in kernel state corruption or denial of service. The published EPSS probability is low, reflecting limited public exploitation activity to date.

Root Cause

The root cause is initialization order. In pcxhr_probe(), the call to request_threaded_irq() occurs before mutex_init(&mgr->lock). Kernel threaded IRQs may execute as soon as the handler is registered, so any hardware interrupt during the narrow probe window drives the handler through code paths that call mutex_lock(&mgr->lock) on memory that has not yet been prepared as a valid mutex.

Attack Vector

The attack vector is local. Triggering the race requires either physical or logical access to a system with the affected hardware present, or the ability to influence driver loading and device interrupt delivery. A local user able to force module reload, device rebind, or induce early interrupt delivery can widen the race window. No user interaction or elevated privileges are required to reach the vulnerable code path once the driver begins probing.

No public proof-of-concept exploit is available for this issue. Refer to the upstream commits, including Kernel Commit 039602d and Kernel Commit 7ef9ad8, for the exact code changes.

Detection Methods for CVE-2026-80967

Indicators of Compromise

Kernel log entries referencing pcxhr initialization failures, mutex lockdep warnings, or IRQ handler faults during boot or module load
Unexpected kernel oopses or soft lockups originating from pcxhr_threaded_irq() in dmesg or journalctl -k output
Repeated driver rebind or module reload activity on systems with Digigram pcxhr audio hardware

Detection Strategies

Inventory running kernels with uname -r and compare against the fixed stable branches referenced in the upstream commit list
Verify whether the snd_pcxhr module is loaded using lsmod | grep pcxhr and audit hosts where the driver is present
Enable kernel lock debugging (CONFIG_DEBUG_MUTEXES, CONFIG_PROVE_LOCKING) on test systems to surface uninitialized mutex use during probe

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM tier and alert on pcxhr warnings, BUG reports, or IRQ subsystem errors
Track module load and unload events with the audit subsystem to detect abnormal driver rebinding on affected hosts
Monitor for unexpected reboots or kernel panics on Linux systems that use ALSA sound hardware in server or workstation roles

How to Mitigate CVE-2026-80967

Immediate Actions Required

Apply the stable kernel updates that include the upstream fixes listed in the NVD references and reboot affected systems
On systems that do not require the driver, blacklist snd_pcxhr in /etc/modprobe.d/ to prevent it from loading
Restrict local access to systems with affected hardware until patched kernels are deployed

Patch Information

The fix moves mutex_init() for mgr->lock before the call to request_threaded_irq() in pcxhr_probe(), ensuring the mutex is valid before any interrupt handler can run. The fix is distributed across seven stable-tree commits, including Kernel Commit 6c97817, Kernel Commit 7cf280f, Kernel Commit a5f405a, Kernel Commit c069b3c, and Kernel Commit ede25b7. Update to the distribution kernel package containing these backports.

Workarounds

Blacklist the vulnerable module with echo "blacklist snd_pcxhr" > /etc/modprobe.d/blacklist-pcxhr.conf on hosts that do not need pcxhr audio support
Physically remove or disable Digigram pcxhr sound hardware from systems where audio functionality is not required
Limit shell access and hotplug privileges to trusted administrators to reduce the ability of local users to influence driver probe timing

bash

# Configuration example: prevent the vulnerable driver from loading
echo "blacklist snd_pcxhr" | sudo tee /etc/modprobe.d/blacklist-pcxhr.conf
sudo depmod -a
sudo update-initramfs -u
# Reboot to ensure the module is not loaded from the initramfs
sudo reboot