CVE-2026-80967

What it actually does

A race in the Linux ALSA pcxhr driver allows a threaded IRQ handler to run during probe before mgr->lock and related manager mutexes are initialized. An early interrupt can therefore take an uninitialized mutex, producing undefined lock behavior that can corrupt kernel memory, deadlock, or panic the kernel, with high impact on local confidentiality, integrity, and availability.

Why it matters to the business

Hosts that load the snd-pcxhr driver for Digigram PCXHR-class audio hardware may crash or, in the worst case, be fully compromised from local access. The issue is not in CISA KEV, has no known exploit maturity, and a very low, flat EPSS (~0.002 over 30 days), so opportunistic mass exploitation is unlikely; risk is concentrated on Linux systems that actually attach this hardware. Published recently (about 20 days), it still warrants timely kernel patching on affected audio/workstation/embedded fleets because CVSS is high (8.4) and impact is kernel-wide.

How an attack unfolds

A local actor on a machine with PCXHR hardware causes or waits for pcxhr_probe() while an interrupt can fire after request_threaded_irq() but before mutex initialization. The threaded handler then operates on uninitialized lock state. That race can panic the host or corrupt kernel synchronization objects; with further local primitives this class of bug can be turned into denial of service or privilege escalation. No public exploit maturity or named threat actors are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix that initializes pcxhr manager mutexes (including mgr->lock) before request_threaded_irq() in pcxhr_probe(), then reboot into the patched kernel. Consume the change via your distro or vendor kernel that includes the ALSA pcxhr 'initialize mutexes before requesting threaded IRQ' commit. If an immediate kernel upgrade is not possible, do not bind or autoload snd-pcxhr (module blacklist / avoid attaching the card) until the patched kernel is deployed. No package-specific fixed version numbers were supplied with this record—track vendor kernel advisories for the exact build.

How to confirm the fix worked

Confirm the running kernel changelog or stable git history contains the pcxhr_probe mutex-init-before-IRQ change; inspect pcxhr_probe so mutex_init of manager locks precedes request_threaded_irq. On hosts, check whether snd-pcxhr is loaded (lsmod) and whether PCXHR hardware is present (lspci/alsa devices). After patching, reload or reboot and verify probe completes without lockdep warnings, mutex BUG messages, or oopses in pcxhr_threaded_irq. Unpatched trees still show IRQ registration before lock initialization.

Typical attack path

1. Obtain local code execution or an unprivileged local foothold on a Linux system that enumerates Digigram PCXHR-compatible audio hardware
2. Cause or wait for snd-pcxhr probe so the threaded IRQ is registered before manager mutexes are initialized
3. Win the probe-time race so pcxhr_threaded_irq runs against uninitialized mgr->lock
4. Induce kernel lock corruption, oops/panic, or further memory-safety failure
5. Leverage the resulting kernel instability or corruption for denial of service or local privilege escalation

How to detect it

This is a probe-time kernel race, not a network worm, so look for evidence the buggy path ran rather than classic malware IOCs. Review kernel logs (journalctl -k, dmesg, /var/log/kern.log) around snd-pcxhr load and device probe for oops/panic, lockdep reports, and mutex 'bad magic' or uninitialized-lock warnings with pcxhr_threaded_irq or pcxhr_probe on the stack. Correlate with module loads of snd-pcxhr, unexpected audio-device rebinds, and sudden reboots. Absence of those artifacts does not prove the race was never hit; presence indicates the vulnerable probe path executed and should be treated as a crash or possible local exploitation attempt. No named APT campaigns are documented for this CVE.

• pcxhr_threaded_irq
• pcxhr_probe
• snd-pcxhr
• BUG:.*mutex.*pcxhr
• lockdep.*pcxhr
• Call Trace:.*pcxhr_threaded_irq
• request_threaded_irq.*pcxhr

What your security team should do

• Inventory Linux hosts for snd-pcxhr / Digigram PCXHR audio hardware and prioritize those for kernel update
• Deploy vendor/distro kernels that include the ALSA pcxhr mutex initialization fix and reboot
• Until patched, blacklist or prevent autoload of snd-pcxhr on systems that do not require the card
• Watch kernel logs for pcxhr probe-time oopses and lockdep/mutex warnings as a sign the race fired
• Treat residual risk as local and hardware-gated; do not delay patching solely because EPSS is low and KEV is false