In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Clear SNDRVTIMERIFLG_DEAD once the close completes
sndtimercloselocked() marks an instance with SNDRVTIMERIFLGDEAD and returns early when the flag is already set, but the flag is never cleared again. A completed close ends in removeslavelinks(), 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 sndtimerinstancefree() frees an object that is still on timer->openlisthead, still on sndtimermasterlist if it was opened with a slave key, still owns any adopted slaves, and still holds its timer and module references.
sndseqtimeropen() reopens an instance exactly like that: it retries its fallback open on the same object after a failure that has already run sndtimercloselocked() internally. An unprivileged user with access to /dev/snd/timer and /dev/snd/seq can force that failure, since sndtimercheckmaster() returns -EBUSY when a pending slave matches the new master's (slaveclass, slaveid) key and the target timer has reached maxinstances, and SNDRVTIMERIOCTLSELECT with devclass = SNDRVTIMERCLASSSLAVE keeps the caller-supplied devsclass, so a sequencer queue's key can be forged. The freed instance is afterwards dereferenced by any further sndtimeropen() on that timer, by sndtimercheck_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 removeslavelinks(), under the same timer->lock that sets it, once the instance is off every list.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74503.json",
"cna_assigner": "Linux"
}