CVE-2026-90116: ALSA: mtpav: shut down output timer before card teardown
In the Linux kernel, the following vulnerability has been resolved:
ALSA: mtpav: shut down output timer before card teardown
sndmtpavoutputtimer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state.
sndmtpavfree() currently takes the same lock and calls timerdelete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer.
A callback running on another CPU can therefore continue after sndmtpavfree() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timerdelete() has returned.
Call timershutdownsync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.52 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1 - Compensating control
In ALSA mtpav card teardown, call timer_shutdown_sync() without holding chip->spinlock before releasing the card-private mtpav state, so running callbacks finish and cannot rearm the timer.
Event History
Frequently Asked Questions
Can removing a pending timer alone prevent this race?
No. timer_delete() does not wait for an already running callback, and it does not stop that callback from rearming the timer after timer_delete() returns.
When can use-after-free access occur?
It can occur when the output timer callback is running on another CPU while the card-private mtpav state is being torn down. The callback may continue after the free path releases the spinlock and access the released state.
What synchronization is required during teardown?
The timer must be shut down with timer_shutdown_sync() without holding chip->spinlock. This waits for any active callback to complete and prevents further timer rearming before the card-private state is released.