CVE-2026-74503: ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes

From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes

snd_timer_close_locked() marks an instance with SNDRV_TIMER_IFLG_DEAD
and returns early when the flag is already set, but the flag is never
cleared again.  A completed close ends in remove_slave_links(), which
leaves timeri->timer NULL, so a second close is already harmless through
the timer == NULL path; the early return can only be reached by an
instance that was opened again in between.  For such an instance the
close unlinks nothing, so snd_timer_instance_free() frees an object that
is still on timer->open_list_head, still on snd_timer_master_list if it
was opened with a slave key, still owns any adopted slaves, and still
holds its timer and module references.

snd_seq_timer_open() reopens an instance exactly like that: it retries
its fallback open on the same object after a failure that has already
run snd_timer_close_locked() internally.  An unprivileged user with
access to /dev/snd/timer and /dev/snd/seq can force that failure, since
snd_timer_check_master() returns -EBUSY when a pending slave matches the
new master's (slave_class, slave_id) key and the target timer has
reached max_instances, and SNDRV_TIMER_IOCTL_SELECT with dev_class =
SNDRV_TIMER_CLASS_SLAVE keeps the caller-supplied dev_sclass, so a
sequencer queue's key can be forged.  The freed instance is afterwards
dereferenced by any further snd_timer_open() on that timer, by
snd_timer_check_slave(), and by /proc/asound/timers, which faults on the
stale ti->owner pointer.

The flag only has to be visible while the close is in progress, which is
all its other users need.  Clear it in remove_slave_links(), under the
same timer->lock that sets it, once the instance is off every list.

The Linux kernel CVE team has assigned CVE-2026-74503 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12.94 with commit 586b219a22b1032b28b8bd356b963276c5e5bf53 and fixed in 6.12.103 with commit bb016091010ec401a06e6bdace0cd944ee03d371
	Issue introduced in 6.18.36 with commit f46093dd22969037beb1fce2e043f3236be41c92 and fixed in 6.18.44 with commit a26a2e52736f9e39843ca66a2e1ce6bf1adbcd1e
	Issue introduced in 7.1 with commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92 and fixed in 7.1.8 with commit 0c561fab50991df10b1e4daca25886c34a2a9c07
	Issue introduced in 7.1 with commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92 and fixed in 7.2-rc6 with commit c2744d5f3aea474513fd2298daecb94a952ce441
	Issue introduced in 7.0.13 with commit 60e73ab87b84bbd6bd7ddd1d16019a3a3705ab8f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74503
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	sound/core/timer.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/bb016091010ec401a06e6bdace0cd944ee03d371
	https://git.kernel.org/stable/c/a26a2e52736f9e39843ca66a2e1ce6bf1adbcd1e
	https://git.kernel.org/stable/c/0c561fab50991df10b1e4daca25886c34a2a9c07
	https://git.kernel.org/stable/c/c2744d5f3aea474513fd2298daecb94a952ce441