CVE-2026-93219 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
clocksource/drivers/timer-sun4i: Advertise a real minimum delta
sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS.
That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events.
Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in the Linux kernel's sun4i timer driver stems from an incorrect configuration of the minimum delta ticks advertised to the clockevents subsystem. This specific issue resides within the allwinner sun4i architecture support, particularly affecting devices like the Allwinner D1 SoC. The root cause lies in how the driver handles synchronization delays between stopping and starting the hardware timer. To compensate for this latency, the function sun4i_clkevt_next_event() subtracts a constant value known as TIMER_SYNC_TICKS from the requested event time before programming it into the hardware interval register. While this compensation is necessary to ensure accurate timing despite hardware latencies, the driver incorrectly advertised TIMER_SYNC_TICKS itself as the minimum delta ticks capability of the device.
This misconfiguration creates a critical logic flaw in the interaction between the kernel's high-resolution timer subsystem and the underlying hardware driver. When the clockevents core determines that it can schedule an event using forced minimum-delta optimizations, it may invoke set_next_event() with an argument equal to TIMER_SYNC_TICKS. Because the driver subtracts this same value from the input before programming the hardware register, the resulting interval programmed into the timer becomes zero ticks. In a system utilizing oneshot mode, high-resolution timers, or nohz idle states, a zero-tick interval effectively disables further timer interrupts for that specific clocksource instance. This causes the next scheduled event to remain stuck indefinitely because the hardware never triggers an interrupt at time zero relative to its current state in this context.
The operational impact of this flaw is severe, manifesting primarily as system boot hangs or kernel panics on affected platforms such as the Allwinner D1. The issue becomes particularly prevalent after updates to the clockevents core that introduced more aggressive reuse of forced minimum-delta events for performance optimization. When these optimizations trigger during early boot processes or critical timing operations, the resulting zero-interval programming leads to a deadlock where the system waits indefinitely for a timer interrupt that will never occur. This disrupts essential kernel activities such as process scheduling, watchdog timers, and power management states, rendering the device unresponsive until a hard reset is performed.
From a vulnerability classification perspective, this defect aligns with CWE-20: Improper Input Validation, specifically regarding the failure to validate or constrain input values against hardware limitations before processing. It also relates to CWE-835: Loop of Death, as the system enters an infinite wait state due to the missing timer interrupt. In terms of MITRE ATT&CK mapping, while this is not a security exploit in the traditional sense, it represents a reliability failure that could be leveraged for Denial of Service if triggered by malicious user-space applications capable of manipulating high-resolution timers or forcing specific scheduling behaviors on affected systems. The vulnerability highlights the importance of strict boundary checking when exposing hardware capabilities to kernel subsystems.
The resolution involves correcting the advertised minimum delta ticks value in the sun4i timer driver configuration. Instead of advertising TIMER_SYNC_TICKS as the minimum, the driver now advertises one extra tick beyond that compensation value. This ensures that even if the clockevents core requests a minimal event equal to the synchronization delay, the actual hardware programming results in at least one valid tick interval rather than zero. This simple adjustment prevents the calculation from collapsing into an invalid state and restores proper timer interrupt generation.
To mitigate similar issues or address this specific vulnerability on affected systems, administrators should apply kernel updates that include the patch for clocksource/drivers/timer-sun4i. For environments where immediate patching is not feasible, monitoring system logs for timeout-related errors during boot can help identify impacted instances early. Furthermore, developers working with embedded Linux platforms should ensure that timer drivers accurately reflect hardware constraints to prevent synchronization delays from causing zero-interval programming scenarios. Regular testing of high-resolution timer functionality under various idle and load conditions is recommended to detect such timing anomalies before they cause system instability in production deployments.