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)
Published: 2026-10-23
Score: 4.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service (Kernel Panic)
Action: Immediate Patch
AI Analysis

Impact

The drm/xe driver’s adjust_idledly() function contains multiple corner‑case conditions that can trigger a divide‑by‑zero or integer overflow, causing the kernel to panic. This results in a denial of service, as the kernel must be rebooted to recover. The weakness is attributable to improper division and overflow handling (CWE‑369).

Affected Systems

This bug is present in the Linux kernel’s DRM (Graphics Direct Rendering Manager) Xe driver before the patch from commit d864065e. All Linux kernel releases that include the drm/xe module and have not applied the fix are affected. No specific major or minor version field was supplied by the CNA, so any kernel containing the described code path is considered vulnerable.

Risk and Exploitability

The exploit requires triggering the problematic code path during device initialization or normal operation, which typically occurs in kernel context when the Xe graphics device is accessed. Because the code runs privileged, the attack vector is local to the machine and does not provide remote code execution. EPSS score is < 1% and CVSS score is 4.7, and the vulnerability is not listed in CISA’s KEV catalog, but the potential for a kernel panic makes the impact severe. If an attacker can induce the driver to initialize with an unrecognized crystal clock or a zero delay value, the system will lose service.

Generated by OpenCVE AI on October 29, 2026 at 13:43 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a kernel update that incorporates the drm/xe adjust_idledly() fix, such as upgrading to a later Linux kernel release where the patch from commit d864065e is included.
  • Reboot the system to ensure the updated driver is loaded and the kernel restarts cleanly.
  • If the Xe graphics driver is not required, consider disabling the /dev/dri device or removing the module to prevent the vulnerable code path from executing.

Generated by OpenCVE AI on October 29, 2026 at 13:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
History

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-369
References
Metrics threat_severity

None

 cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Fri, 23 Oct 2026 16:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
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)
Title drm/xe: harden adjust_idledly() against divide-by-zero and overflow
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-23T12:05:08.723Z

Reserved: 2026-09-25T10:25:14.380Z

Link: CVE-2026-98919

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:12.487

Modified: 2026-10-23T13:17:12.487

Link: CVE-2026-98919

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-98919 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T13:45:17Z

Weaknesses