# CVE-2026-98919: linux: In the Linux kernel, the following vulnerability has been resolved:  drm/xe: harden adjust_idledly() against divide-b...

CVE-2026-98919 is fixed in linux on 1 platform by DEBIAN-CVE-2026-98919 (version 7.2.9-1), released October 24, 2026. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2026-98919
- Priority: Routine
- CVSS: n/a
- EPSS: 0.0017
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Oct 23, 2026

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

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 14 | 7.2.9-1 | [DEBIAN-CVE-2026-98919](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98919.md) | Oct 24, 2026 |

---

Data as of 2026-11-08T19:12:23Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.