In the Linux kernel, the following vulnerability has been resolved:
ALSA: harmony: initialize locks before requesting IRQ
snd_harmony_create() registers the IRQ before initializing h->lock and
h->mixer_lock. A pending interrupt can invoke the handler while these
locks are uninitialized.
Initialize both locks before requesting the IRQ so the handler always
sees valid lock state.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.4
AV:L - The bug is reached only from snd_harmony_probe() → snd_harmony_create() → request_irq() → snd_harmony_interrupt() on onboard HP PA-RISC LASI/ASP Harmony audio, which enumerates at boot or module bind. There is no network, Bluetooth, or USB packet path into this GSC chip.
AC:L - snd_harmony_create() calls request_irq() before spin_lock_init() and before pcm_init()'s harmony_disable_interrupts(). Firmware leftover DSTATUS_IE plus pending PN/RN lets gsc_asic_unmask_irq() deliver snd_harmony_interrupt() immediately against uninitialized h->lock, without an attacker-uncontrollable race.
PR:N - snd_harmony_create() performs no capability or authentication checks before request_irq(). On GSC/LASI PA-RISC workstations and servers with Harmony, kernel/udev enumeration runs the vulnerable probe automatically without an OS account or user-namespace privilege.
UI:N - No victim action is required. A pending Harmony interrupt during driver probe at boot or module autoload invokes the uninitialized-lock IRQ path without anyone opening ALSA PCM or control nodes.
S:U - Impact is uninitialized spinlock use and DMA next-address programming inside the host kernel Harmony driver. This does not cross a VM, IOMMU, or sandbox security boundary.
C:H - snd_harmony_interrupt() takes uninitialized h->lock in hard-IRQ context and, with psubs/csubs still NULL, programs HARMONY_PNXTADD from zeroed sdma so the chip DMAs from physical address 0. That undefined lock/DMA behavior can disclose kernel memory rather than a small bounded leak.
I:H - On SMP PA-RISC (defconfig), probe can spin_lock_init() h->lock while the IRQ handler still holds the zeroed lock, and the handler writes HARMONY_RNXTADD/PNXTADD (including 0) in that window. That lock-state corruption and invalid DMA programming are write/control-flow primitives, not a pure crash.
A:H - Taking uninitialized h->lock in snd_harmony_interrupt() during probe hits DEBUG_SPINLOCK bad-magic BUG, lockdep non-static-key failure, oops/panic, or a hung IRQ/DMA path on affected PA-RISC machines, fully denying availability.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only from snd_harmony_probe() → snd_harmony_create() → request_irq() → snd_harmony_interrupt() on onboard HP PA-RISC LASI/ASP Harmony audio, which enumerates at boot or module bind. There is no network, Bluetooth, or USB packet path into this GSC chip.
AC:L - snd_harmony_create() calls request_irq() before spin_lock_init() and before pcm_init()'s harmony_disable_interrupts(). Firmware leftover DSTATUS_IE plus pending PN/RN lets gsc_asic_unmask_irq() deliver snd_harmony_interrupt() immediately against uninitialized h->lock, without an attacker-uncontrollable race.
PR:N - snd_harmony_create() performs no capability or authentication checks before request_irq(). On GSC/LASI PA-RISC workstations and servers with Harmony, kernel/udev enumeration runs the vulnerable probe automatically without an OS account or user-namespace privilege.
UI:N - No victim action is required. A pending Harmony interrupt during driver probe at boot or module autoload invokes the uninitialized-lock IRQ path without anyone opening ALSA PCM or control nodes.
S:U - Impact is uninitialized spinlock use and DMA next-address programming inside the host kernel Harmony driver. This does not cross a VM, IOMMU, or sandbox security boundary.
C:H - snd_harmony_interrupt() takes uninitialized h->lock in hard-IRQ context and, with psubs/csubs still NULL, programs HARMONY_PNXTADD from zeroed sdma so the chip DMAs from physical address 0. That undefined lock/DMA behavior can disclose kernel memory rather than a small bounded leak.
I:H - On SMP PA-RISC (defconfig), probe can spin_lock_init() h->lock while the IRQ handler still holds the zeroed lock, and the handler writes HARMONY_RNXTADD/PNXTADD (including 0) in that window. That lock-state corruption and invalid DMA programming are write/control-flow primitives, not a pure crash.
A:H - Taking uninitialized h->lock in snd_harmony_interrupt() during probe hits DEBUG_SPINLOCK bad-magic BUG, lockdep non-static-key failure, oops/panic, or a hung IRQ/DMA path on affected PA-RISC machines, fully denying availability.
CVSS 3.1