---
id: "CVE-2026-98919"
kind: "vulnerability"
aliases: ["CVE-2026-98919"]
title: "Linux kernel: Intel Xe GPU driver idle-delay setup can divide by zero and panic"
severity: "unknown"
cvss: null
epss: 0.00206
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["drm", "infrastructure", "intel-xe", "kernel", "linux", "self-hosted"]
not_affected_if: ["no-intel-xe-driver", "non-intel-gpu"]
published_at: "2026-10-23T13:17:12+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98919", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98919", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: Intel Xe GPU driver idle-delay setup can divide by zero and panic

The Intel Xe graphics driver in the Linux kernel could divide by zero or overflow while computing the GPU idle delay when the crystal clock is not recognised, which panics the kernel. The sources do not describe an attacker-controlled trigger, so the impact is a kernel crash during driver initialisation on affected hardware.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the kernel includes the Xe driver: `grep -i xe /proc/modules` or `lsmod | grep xe` on a system with Intel Arc or recent Intel integrated graphics.
- Compare the running kernel to the fixed commit d864065ea25e9d12897c175de9176ce46677e176 in the stable kernel branch for your release.

## Fix

- Update the Linux kernel to a stable release that contains commit d864065ea25e9d12897c175de9176ce46677e176 (version unknown from the sources).
- Until patched, unknown.

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98919
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98919

## From the sources

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)

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_