Cloudanix VulnDB

CVE-2026-31767

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

May 1, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some Linux systems with certain Intel display hardware can crash when the graphics driver loads or changes display settings, so affected machines should be updated.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is a local denial-of-service flaw in the Linux kernel Intel i915 display driver, specifically in the DSI Display Stream Compression timing logic. In command mode, the driver incorrectly adjusts horizontal timing values based on the compression ratio, behavior intended only for video mode. On affected systems, the adjusted horizontal total can become so small that a later calculation produces a zero line-time value, leading to a divide-by-zero condition when the driver calculates vertical timing. The result can be a kernel crash or panic when the i915 driver initializes or processes the affected display configuration. The issue impacts availability only; it does not directly provide code execution, privilege escalation, or data disclosure based on the available information.

Why it matters to the business

Systems using affected Linux kernels with vulnerable Intel i915 DSI display configurations may crash locally, causing workstation, kiosk, embedded, or laptop outages. Because exploitation requires local access and the current EPSS score is very low with no known exploited-in-the-wild or ransomware association, broad internet-scale risk is low. Operational impact is highest for fleets with affected hardware where display initialization occurs during boot, resume, graphical session startup, or driver reload, because the system may become unstable or unavailable until patched or mitigated.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel on hardware that exercises the vulnerable Intel i915 DSI command-mode path with DSC timing calculations. The attacker then triggers the vulnerable code path by causing the i915 display driver to initialize, reload, resume, or apply a display configuration that reaches the faulty timing logic. Because the driver performs command-mode horizontal timing adjustment incorrectly, it may compute an invalidly small horizontal total, resulting in a zero line-time value. When the kernel later divides by that value while calculating vertical timing, the kernel can hit a divide-by-zero exception and crash. There is no indication from the provided data that this vulnerability is remotely exploitable or currently used by named threat actors.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream i915 DSI fix from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525 or the corresponding distribution backport. No exact fixed package versions were provided, so rely on the affected distribution or hardware vendor advisory for the patched kernel version. After patching, reboot into the updated kernel and ensure the vulnerable older kernel is not selected by default. Where immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, preventing untrusted users from loading or unloading kernel modules, restricting access to display configuration controls where feasible, and avoiding affected hardware/display configurations until patched. As a temporary operational mitigation on systems where graphics acceleration is not required, consider disabling the affected i915 driver path or using a safe fallback graphics configuration, but validate carefully because this may reduce display functionality.

How to confirm the fix worked

Confirm exposure by checking whether the system runs an affected Linux kernel build and uses the Intel i915 driver on hardware with DSI/DSC display paths. Validate remediation by confirming the running kernel version is a vendor-fixed build or contains the upstream fix commit/backport, then reboot and verify the patched kernel is active with tools such as uname and package manager metadata. Review kernel logs after boot, resume, graphical login, and display mode changes to confirm there are no divide-by-zero, kernel oops, panic, or i915 DSI timing errors. For source-based validation, confirm that the i915 DSI logic no longer performs DSC horizontal timing adjustments in command mode. For fleet validation, inventory Linux systems using i915 and prioritize those with laptops, tablets, kiosks, or embedded devices where DSI panels are common.

Typical attack path

  1. Obtain local access to an affected Linux system with a vulnerable kernel and susceptible Intel i915 DSI display configuration.
  2. Identify that the system uses the i915 display driver and a display mode path that can exercise DSI command mode with DSC timing logic.
  3. Trigger display driver initialization or reconfiguration, such as through boot, resume, graphical display setup, driver reload, or display mode changes.
  4. Cause the vulnerable timing calculation to produce a zero line-time value.
  5. Trigger the divide-by-zero condition in kernel display timing code.
  6. Crash or panic the kernel, resulting in local denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal records, crash dumps, and endpoint telemetry for local kernel crashes involving the i915 display driver, DSI, DSC, or divide-by-zero exceptions. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, systemd journal persistence, kdump/vmcore records, pstore/ramoops, apport/ABRT crash reports, and EDR telemetry for local users running display configuration tools or commands around the time of a crash. Look for crashes occurring during boot, resume from sleep, graphical login, display mode changes, modprobe/rmmod activity for i915, or execution of tools such as xrandr, weston, sway, gnome-shell, mutter, kwin, or display settings helpers. Attribution to malicious exploitation may be difficult because the vulnerable path can also be triggered accidentally by normal hardware initialization; prioritize cases with repeated crashes correlated with the same local user, scripted display changes, driver reloads, or unusual local access immediately before the kernel fault.

  • divide error
  • divide-by-zero
  • divide by zero
  • kernel BUG
  • kernel panic
  • Oops:
  • RIP:
  • drm/i915/dsi
  • i915
  • intel_dsi
  • DSI
  • DSC
  • line_time_us
  • vtotal
  • htotal
  • modprobe i915
  • rmmod i915
  • /var/log/kern.log
  • /var/log/messages
  • /var/log/syslog
  • /sys/fs/pstore
  • /var/crash
  • vmcore

What your security team should do

  • Prioritize patching systems that use Intel i915 graphics with DSI panels, especially laptops, tablets, kiosks, and embedded endpoints where a display-driver crash can disrupt operations.
  • Deploy vendor-fixed Linux kernel updates and reboot systems so the fixed kernel is active.
  • Inventory hosts loading the i915 driver and correlate with kernel versions to identify potentially exposed systems.
  • Because exploitation requires local access, focus compensating controls on limiting untrusted local users, shell access, and permissions to manipulate display or kernel module state.
  • Monitor kernel logs and crash reporting for i915-related divide-by-zero, oops, panic, or general protection fault events.
  • If repeated crashes are observed before patching, consider temporarily disabling the affected graphics path or moving critical systems to fallback display configurations after operational testing.
  • Do not treat this as an internet-facing emergency based on the current data: EPSS is very low, exploit maturity is listed as none, and it is not in the Known Exploited Vulnerabilities catalog.

The record

In the Linux kernel, the following vulnerability has been resolved: drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things. This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode. Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads. (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities