CVE-2026-98919 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: harden adjust_idledly() against divide-by-zero and overflow
adjust_idledly() has several corner-case issues flagged during review:
1. If xe_gt_clock_init() failed to recognise the crystal clock, gt->info.timestamp_base is 0, which makes idledly_units_ps also 0. The subsequent DIV_ROUND_CLOSEST(..., idledly_units_ps) is then a divide-by-zero and panics the kernel.
2. The tick-to-ns conversions are done in u32: idledly * idledly_units_ps, (maxcnt - 1) * 1000 Both overflow u32 before DIV_ROUND_CLOSEST() sees them.
3. If IDLE_WAIT_TIME reads back as 0, maxcnt evaluates to 0 and the maxcnt - 1 clamp wraps to 0xFFFFFFFF in u32.
4. The register only stores whole ticks, so the clamped ns value has to be converted to ticks and back. DIV_ROUND_CLOSEST() can round that conversion up past maxcnt:
maxcnt = 640 ns, one tick = 666664 ps
clamp: maxcnt - 1 = 639 ns ns -> ticks: 639000 / 666664 = 0.958 -> rounds to 1 tick tick -> ns: 1 * 666664 / 1000 = 667 ns
667 ns is programmed into RING_IDLEDLY, but 667 >= maxcnt (640), so xe_gt_WARN_ON() fires again on every subsequent init.
Return early if timestamp_base is 0 (the unknown-crystal path). Do the conversions in u64 via the *_ULL() helpers so they cannot wrap. Clamp with a floor (DIV_ROUND_DOWN_ULL) so the programmed delay stays strictly below maxcnt, and guard the maxcnt == 0 case with a zero delay while still writing RING_IDLEDLY so INHIBIT_SWITCH_UNTIL_PREEMPTED is cleared.
v2: Drop the redundant warn on the timestamp_base == 0 path; xe_gt_clock_init() already warns on an unrecognised crystal clock. Keep the early return to avoid the divide-by-zero. - Vinay
v3: Field-mask the RING_IDLEDLY write with REG_FIELD_PREP(IDLE_DELAY, ...) instead of writing the raw tick count, which could clobber INHIBIT_SWITCH_UNTIL_PREEMPTED and reserved bits. Split the inhibit-switch clear from the maxcnt clamp so a set inhibit bit no longer forces a needless delay overwrite when the delay itself is already valid. Use gt_to_xe(gt) instead of gt_to_xe(hwe->gt).
(cherry picked from commit d864065ea25e9d12897c175de9176ce46677e176)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel driver for Intel Xe graphics contains a critical vulnerability within the adjust_idledly function that exposes the system to denial of service conditions through integer overflow and divide-by-zero errors. This flaw resides in the power management logic responsible for configuring idle delay timers, specifically when initializing or reconfiguring GPU ground truth clock parameters. The root cause stems from insufficient validation of hardware-reported values and inadequate use of data types during arithmetic operations involving time conversions. When the kernel attempts to calculate optimal idle wait times based on crystal clock frequencies, it relies on variables that may contain zero or near-zero values under specific hardware states or initialization failures. These unchecked inputs propagate through mathematical functions without proper bounds checking, leading to catastrophic runtime errors that compromise system stability and availability.
A primary vector for exploitation involves the divide-by-zero condition triggered when xe_gt_clock_init fails to recognize a valid crystal clock source. In such scenarios, the gt->info.timestamp_base variable remains at zero, which cascades into idledly_units_ps also being set to zero. The subsequent call to DIV_ROUND_CLOSEST performs division by this zero value, causing an immediate kernel panic. This represents a classic CWE-369 divide-by-zero vulnerability where input validation is absent for hardware-dependent configuration values that can legitimately be null during boot sequences or when encountering unsupported hardware configurations. An attacker with local access could potentially trigger this state through specific driver load conditions or by manipulating device states to force clock initialization failures, resulting in immediate system crash and denial of service without requiring elevated privileges beyond basic user space interaction with the graphics subsystem.
Beyond division errors, the vulnerability includes severe integer overflow issues within tick-to-nanosecond conversions. The original implementation utilizes unsigned 32-bit integers for calculations involving idledly multiplied by idledly_units_ps and maxcnt minus one multiplied by one thousand. These multiplications can easily exceed the maximum value representable in a u32, causing silent wraparound before DIV_ROUND_CLOSEST processes the result. This CWE-190 integer overflow leads to incorrect delay values being programmed into hardware registers, potentially resulting in unpredictable behavior or further arithmetic errors downstream. Additionally, if IDLE_WAIT_TIME reads back as zero from the hardware register, maxcnt evaluates to zero, and subtracting one causes unsigned wraparound to 0xFFFFFFFF. This extreme value then propagates through subsequent calculations, creating massive incorrect delay values that disrupt power management logic and potentially cause thermal or performance anomalies due to improper idle state transitions.
The vulnerability also encompasses logical errors in rounding behavior that violate hardware constraints. Since the RING_IDLEDLY register stores only whole ticks, conversions between nanoseconds and tick counts involve rounding operations that can exceed maximum allowed limits even when inputs appear valid. For instance, a maxcnt of 640 nanoseconds with a tick duration of approximately 666 microseconds may result in rounded values exceeding the limit after conversion back from ticks to nanoseconds. This causes xe_gt_WARN_ON assertions to fire repeatedly during initialization, indicating persistent configuration failures that degrade system reliability and generate excessive logging overhead. The lack of proper floor-based clamping allows these boundary violations to persist, undermining the integrity of power management controls and potentially leading to resource exhaustion or functional degradation in long-running systems relying on precise idle timing for energy efficiency.
Mitigation strategies implemented in the patch address these issues through rigorous input validation and type promotion techniques. The code now returns early if timestamp_base is zero, effectively bypassing dangerous calculations when hardware clock information is unavailable. All arithmetic conversions are performed using unsigned 64-bit integers via specialized helper functions to prevent overflow wraparound during multiplication operations. Clamping mechanisms utilize floor-based rounding to ensure programmed delays remain strictly below maximum thresholds, eliminating the risk of exceeding register limits due to rounding artifacts. Special handling for zero maxcnt cases ensures that delay values do not wrap around while still maintaining necessary hardware state bits like INHIBIT_SWITCH_UNTIL_PREEMPTED through field-masked writes rather than raw value overwrites. These changes align with CWE-20 input validation principles and mitigate risks associated with improper neutralization of special elements in data processing operations.
From a threat modeling perspective, this vulnerability maps to ATT&CK technique T1499 endpoint denial of service via resource exhaustion or system crash mechanisms. Local attackers could exploit the divide-by-zero condition to trigger kernel panics without authentication if they can influence driver initialization paths through device removal and reinsertion sequences or by triggering specific power state transitions that expose uninitialized clock parameters. The integer overflow aspects represent additional attack surfaces where crafted inputs might lead to unexpected behavior in timing-sensitive operations, potentially affecting real-time graphics performance or causing subtle data corruption in timekeeping subsystems dependent on accurate idle delay calculations. Security practitioners should prioritize applying this patch to systems running affected kernel versions, particularly those utilizing Intel Xe integrated graphics solutions that rely heavily on dynamic power management features for thermal and energy efficiency optimization.