In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix race between non-atomic ops and trigger-start
We protect the races of the concurrent state transitions between
atomic PCM ops, but the checks between the non-atomic ops (hw_params,
hw_free and prepare) and the atomic ops aren't perfect; there is a
check of the conflicting PCM state at the beginning of hw_params & co,
but the atomic PCM ops can be still issued during the non-atomic PCM
operations. An example such scenario is that a thread A re-issues the
PREPARE or HW_PARAMS for the already prepared stream, while another
thread B triggers the PCM start in the middle of the prepare
operation. Although this usually doesn't lead to much serious issues,
it can give some inconsistency as reported by syzkaller (such as
ODEBUG warning).
There are various atomic PCM ops, and basically the only problem is
the PCM start as it operates from the PREPARED state. Other trigger
commands (stop, etc) are for the running or the other special state,
hence they are filtered as pre-condition.
This patch is for preventing the PCM trigger-start during the non-
atomic operations in order to address the problems above.
Fortunately, the hw_params, hw_free and prepare operations call
snd_pcm_buffer_access_lock(), and this can be used for checking the
concurrent operations at the PCM trigger -- which sets the
runtime->buffer_accessing to a negative (if possible), so the PCM
trigger just needs to check the runtime->buffer_accessing value; if
it's negative, it means the concurrent non-atomic PCM ops is running.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The race is reached only through local ALSA PCM character devices (/dev/snd/pcmCD) via concurrent open/ioctl syscalls (SNDRV_PCM_IOCTL_HW_PARAMS, HW_FREE, PREPARE versus START). There is no network or Bluetooth path into snd_pcm_pre_start(); USB-gadget snd_pcm_kernel_ioctl is a lower-severity physical path.
AC:L - The attacker controls both sides by issuing PREPARE/HW_PARAMS/HW_FREE on one thread while another issues SNDRV_PCM_IOCTL_START on the same prepared PCM fd. Syzbot produced a C reproducer of the dummy hrtimer race, so success does not depend on conditions outside attacker control.
PR:L - snd_pcm_open() and the PCM ioctl path perform no capability check. Any local user who can open /dev/snd/pcm* (audio group or systemd-logind uaccess on desktops and phones) can trigger the race; real root or init-namespace CAP_SYS_ADMIN is not required.
UI:N - The attacker performs every step themselves—open, hw_params, prepare, start, and close—on their own PCM file descriptors and threads. No separate victim action such as mounting a filesystem or opening a malicious file is required.
S:U - The dangling hrtimer and any DMA-buffer use-after-free remain inside the host kernel ALSA PCM subsystem. This is standard kernel memory corruption, not a VM escape, IOMMU/DMA boundary bypass, or other cross-authority impact.
C:H - Syzbot reports ODEBUG "free active" of the dummy_hrtimer_pcm hrtimer in dummy_pcm_close, so dummy_hrtimer_callback can run after kfree. On real hardware, START during hw_free can DMA from a freed PCM buffer. Per CNA UAF guidance this enables high-impact disclosure.
I:H - The freed dummy_hrtimer_pcm (or hardware DMA pages freed by hw_free/hw_params while trigger-start is running) can be reclaimed; the hrtimer callback then invokes snd_pcm_period_elapsed on attacker-controlled memory, and in-flight DMA can write freed pages, yielding write and control-flow primitives.
A:H - Freeing an armed hrtimer and racing PCM start against buffer teardown dereference freed kernel memory, causing oops or panic. Syzbot reproduced the ODEBUG WARN on dummy close, and the UAF remains a system-wide crash even without a full exploit.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The race is reached only through local ALSA PCM character devices (/dev/snd/pcmCD) via concurrent open/ioctl syscalls (SNDRV_PCM_IOCTL_HW_PARAMS, HW_FREE, PREPARE versus START). There is no network or Bluetooth path into snd_pcm_pre_start(); USB-gadget snd_pcm_kernel_ioctl is a lower-severity physical path.
AC:L - The attacker controls both sides by issuing PREPARE/HW_PARAMS/HW_FREE on one thread while another issues SNDRV_PCM_IOCTL_START on the same prepared PCM fd. Syzbot produced a C reproducer of the dummy hrtimer race, so success does not depend on conditions outside attacker control.
PR:L - snd_pcm_open() and the PCM ioctl path perform no capability check. Any local user who can open /dev/snd/pcm* (audio group or systemd-logind uaccess on desktops and phones) can trigger the race; real root or init-namespace CAP_SYS_ADMIN is not required.
UI:N - The attacker performs every step themselves—open, hw_params, prepare, start, and close—on their own PCM file descriptors and threads. No separate victim action such as mounting a filesystem or opening a malicious file is required.
S:U - The dangling hrtimer and any DMA-buffer use-after-free remain inside the host kernel ALSA PCM subsystem. This is standard kernel memory corruption, not a VM escape, IOMMU/DMA boundary bypass, or other cross-authority impact.
C:H - Syzbot reports ODEBUG "free active" of the dummy_hrtimer_pcm hrtimer in dummy_pcm_close, so dummy_hrtimer_callback can run after kfree. On real hardware, START during hw_free can DMA from a freed PCM buffer. Per CNA UAF guidance this enables high-impact disclosure.
I:H - The freed dummy_hrtimer_pcm (or hardware DMA pages freed by hw_free/hw_params while trigger-start is running) can be reclaimed; the hrtimer callback then invokes snd_pcm_period_elapsed on attacker-controlled memory, and in-flight DMA can write freed pages, yielding write and control-flow primitives.
A:H - Freeing an armed hrtimer and racing PCM start against buffer teardown dereference freed kernel memory, causing oops or panic. Syzbot reproduced the ODEBUG WARN on dummy close, and the UAF remains a system-wide crash even without a full exploit.
CVSS 3.1