CVE-2026-74504 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix division by zero in initialize_timer()
A userspace-driven ALSA timer (SND_UTIMER) lets an unprivileged user set the backing snd_timer's hardware resolution to an arbitrary 64-bit value via SNDRV_TIMER_IOCTL_CREATE. snd_utimer_create() only rejects zero.
When such a timer is bound to a sequencer queue, initialize_timer() computes the tick period as
tmr->ticks = 1000000000 / (r * freq);
where r is that user-controlled resolution and freq is the sequencer update rate in Hz, clamped to MIN_FREQUENCY..MAX_FREQUENCY (10..6250). A resolution of 2^63 makes the 64-bit product r * freq wrap to zero for any even freq, including DEFAULT_FREQUENCY (1000), so the division faults with a divide-by-zero.
The division runs under tmr->lock with interrupts disabled, so the oops leaves the spinlock held and hangs the CPU. It is reachable by an unprivileged user with access to /dev/snd/timer and /dev/snd/seq.
Oops: divide error: 0000 [#1] SMP KASAN PTI
CPU: 7 UID: 1000 PID: 456 Comm: alsa_seq_utimer Not tainted 7.2.0-rc4+ RIP: 0010:initialize_timer.constprop.0+0x20a/0x2d0 snd_seq_timer_start+0x15e/0x2b0 snd_seq_control_queue+0x56f/0xba0 snd_seq_write+0x3e0/0x730
Reject an overflowing product with check_mul_overflow() and fall back to a single tick, which also avoids feeding a wrapped-but-nonzero divisor (e.g. 2^63 * 1000 mod 2^64 == 0, or other resolutions wrapping to a small value) into the period computation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the Linux kernel's Advanced Linux Sound Architecture implementation, specifically in the sequencer subsystem where ALSA handles audio timing operations. This flaw manifests as a division by zero error in the initialize_timer() function that occurs when processing user-controlled timer parameters. The issue stems from insufficient input validation during the creation of userspace-driven ALSA timers, particularly those utilizing the SND_UTIMER interface which allows unprivileged users to configure hardware timer resolution through the SNDRV_TIMER_IOCTL_CREATE ioctl call.
The technical execution path begins with a user-space process opening access to /dev/snd/timer and /dev/snd/seq devices, enabling them to create a timer with an arbitrary 64-bit resolution value. While the snd_utimer_create() function properly rejects zero values, it fails to validate whether the resulting product of user-provided resolution (r) and sequencer update frequency (freq) will cause arithmetic overflow during subsequent calculations. When a resolution value of 2^63 is used in conjunction with any even sequencer frequency including the default 1000 Hz, the multiplication r * freq produces a result that wraps around to zero in 64-bit arithmetic due to integer overflow.
The computational flaw occurs in the specific line where tmr->ticks = 1000000000 / (r * freq); executes, with r representing the user-controlled resolution and freq being the sequencer update rate within the restricted range of 10 to 6250 Hz. When r equals 2^63, even a single even frequency value causes the product to overflow to zero, leading directly to the division by zero exception that crashes the kernel. The vulnerability is particularly dangerous because this division operation executes under a spinlock (tmr->lock) with interrupts disabled, creating a deadlock condition where the CPU hangs indefinitely due to the held spinlock and unhandled exception.
This security issue represents a classic case of integer overflow leading to a denial-of-service condition, categorized by CWE-191 as "Integer Underflow (Wrap or Wraparound)" and also aligns with CWE-369 as "Division by Zero" in kernel contexts. The operational impact extends beyond simple system hanging since this vulnerability can be exploited by unprivileged users who have access to the audio subsystem devices, making it particularly concerning for multi-user systems where sandboxing is expected to prevent such direct kernel interface access. The exploitation requires minimal privileges and leverages legitimate kernel interfaces, making detection and prevention challenging.
The fix implemented addresses the root cause by incorporating overflow checking using check_mul_overflow() before performing the arithmetic operation that could lead to division by zero. When an overflow condition is detected, the system falls back to a single tick calculation rather than allowing the wrapped result to propagate into the subsequent period computation. This defensive programming approach prevents both the immediate divide-by-zero error and also protects against edge cases where the overflowed product might produce seemingly valid but incorrect values that could still cause timing disruptions. The solution follows established kernel security practices for handling arithmetic operations with user-supplied inputs, preventing similar issues across the kernel's timer subsystem and aligning with ATT&CK technique T1499.001 for Network Denial of Service through system resource exhaustion or kernel crashes.
The vulnerability demonstrates the critical importance of validating all user inputs in kernel space operations, particularly when dealing with arithmetic calculations that involve multiple variables where overflow conditions can occur. The fix ensures proper handling of edge cases while maintaining system stability and preventing the potential for more serious security implications such as privilege escalation or information disclosure through carefully crafted timing attacks that could exploit similar overflow conditions in other parts of the kernel's audio subsystem.