CVE-2026-98919: drm/xe: harden adjust_idledly() against divide-by-zero and overflow
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: harden adjustidledly() against divide-by-zero and overflow
adjustidledly() has several corner-case issues flagged during review:
1. If xegtclockinit() failed to recognise the crystal clock, gt->info.timestampbase is 0, which makes idledlyunitsps also 0. The subsequent DIVROUNDCLOSEST(..., idledlyunitsps) is then a divide-by-zero and panics the kernel.
2. The tick-to-ns conversions are done in u32: idledly idledlyunitsps, (maxcnt - 1) 1000 Both overflow u32 before DIVROUNDCLOSEST() sees them.
3. If IDLEWAITTIME 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. DIVROUNDCLOSEST() 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 RINGIDLEDLY, but 667 >= maxcnt (640), so xegtWARNON() fires again on every subsequent init.
Return early if timestampbase is 0 (the unknown-crystal path). Do the conversions in u64 via the ULL() helpers so they cannot wrap. Clamp with a floor (DIVROUNDDOWNULL) so the programmed delay stays strictly below maxcnt, and guard the maxcnt == 0 case with a zero delay while still writing RINGIDLEDLY so INHIBITSWITCHUNTILPREEMPTED is cleared.
v2: Drop the redundant warn on the timestampbase == 0 path; xegtclockinit() already warns on an unrecognised crystal clock. Keep the early return to avoid the divide-by-zero. - Vinay
v3: Field-mask the RINGIDLEDLY write with REGFIELDPREP(IDLEDELAY, ...) instead of writing the raw tick count, which could clobber INHIBITSWITCHUNTILPREEMPTED 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 gttoxe(gt) instead of gttoxe(hwe->gt).
(cherry picked from commit d864065ea25e9d12897c175de9176ce46677e176)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In drm/xe adjust_idledly(), return early with a zero delay when gt->info.timestamp_base is 0 or maxcnt is 0, preventing divide-by-zero on the unknown-crystal path.
- Compensating control
In drm/xe adjust_idledly(), perform tick-to-nanosecond and nanosecond-to-tick conversions with the *_ULL() helpers and clamp the programmed delay strictly below maxcnt using DIV_ROUND_DOWN_ULL, avoiding u32 overflow and the maxcnt - 1 wraparound.
- Compensating control
When writing RING_IDLEDLY, use REG_FIELD_PREP(IDLE_DELAY, ...) to field-mask the delay so INHIBIT_SWITCH_UNTIL_PREEMPTED and reserved bits are not clobbered.