Cloudanix VulnDB

CVE-2026-98919

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux graphics driver can make the computer crash during startup on some hardware.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Division by zero or u32 integer overflow in adjust_idledly() during Intel Xe graphics initialization causes kernel panic when timestamp_base is zero or when tick-to-nanosecond conversions wrap or round incorrectly.

Why it matters to the business

Unexpected system crashes on affected Linux kernels can interrupt workloads, require reboots, and reduce availability for systems using certain Intel graphics hardware.

How an attack unfolds

An attacker with the ability to trigger graphics driver initialization on a system where the crystal clock is unrecognized or under crafted register conditions can force the divide-by-zero or overflow path, resulting in a kernel panic.

How to fix it

Update to a Linux kernel containing the fix from commit d864065ea25e9d12897c175de9176ce46677e176 that adds early return for zero timestamp_base, performs conversions in u64, and uses safe clamping with REG_FIELD_PREP.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; boot with affected hardware and verify no divide-by-zero panic or RING_IDLEDLY warning occurs during graphics initialization.

Typical attack path

  1. Gain local access or cause driver reload on a vulnerable Linux system
  2. Trigger xe_gt_clock_init failure or IDLE_WAIT_TIME read of zero
  3. Execute code path that calls adjust_idledly()
  4. Induce divide-by-zero or u32 overflow leading to kernel panic

How to detect it

Review kernel logs for panic messages mentioning divide-by-zero in adjust_idledly, timestamp_base zero, or repeated xe_gt_WARN_ON on RING_IDLEDLY writes.

What your security team should do

  • Prioritize kernel upgrade on all systems using Intel Xe graphics
  • Monitor for kernel oops or panic logs referencing adjust_idledly or RING_IDLEDLY
  • Test driver initialization in lab environments before broad rollout

The record

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)

Affected packages

Ecosystem Package Introduced Fixed