All vulnerabilities
CVE-2026-98919

Linux: drm/xe: harden adjust_idledly() against divide-by-zero and overflow

Linux LinuxOperating systems
CVSS
NoneNot scored
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)No scoreNo FIRST EPSS score in this snapshot yet
Fixed in2bcbfc5e7bfa9cc76818c54db698da5bdc13d9ffAlso 531d4cd03118224022dc21ae25af052ce2a9e267, 90f467577ebc28c5bc4ba2f0f1b83a4419fb0740CVE List
Published23 Oct 2026Updated 23 Oct 2026CVE List

What fixes it

  • 2bcbfc5e7bfa9cc76818c54db698da5bdc13d9ffLinuxCVE List
  • 531d4cd03118224022dc21ae25af052ce2a9e267LinuxCVE List
  • 90f467577ebc28c5bc4ba2f0f1b83a4419fb0740LinuxCVE List

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

Description

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.

  1. 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.

  1. If IDLE_WAIT_TIME reads back as 0, maxcnt evaluates to 0 and

the maxcnt - 1 clamp wraps to 0xFFFFFFFF in u32.

  1. 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)

Text from CVE List

Affected versions 8

  • Linuxaffected: d2de4410a88ffc6053300d03041cc73b8c85dbaf before 2bcbfc5e7bfa9cc76818c54db698da5bdc13d9ffCVE List
  • Linuxaffected: d2de4410a88ffc6053300d03041cc73b8c85dbaf before 531d4cd03118224022dc21ae25af052ce2a9e267CVE List
  • Linuxaffected: d2de4410a88ffc6053300d03041cc73b8c85dbaf before 90f467577ebc28c5bc4ba2f0f1b83a4419fb0740CVE List
  • Linuxaffected: 6.15CVE List
  • Linuxunaffected: all versions before 6.15CVE List
  • Linuxunaffected: 6.18.55 through 6.18.*CVE List
  • Linuxunaffected: 7.2.9 through 7.2.*CVE List
  • Linuxunaffected: 7.3CVE List

References 3