drm/amd/display: fix division by zero in get_estimated_bw() (CVE-2026-90035) | HOL Guard CVE

Unknown severity · Source severity not reportedCVE-2026-90035

drm/amd/display: fix division by zero in get_estimated_bw()

Answer in brief

CVE-2026-90035 records a Unknown severity vulnerability in drm/amd/display: fix division by zero in get_estimated_bw(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Sep 16, 2026Updated Sep 16, 2026Source checked Sep 16, 2026First seen by HOL Sep 16, 2026Material review Sep 16, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=8e5cfe547bf3beeb29d9608be68d22dff2b5012b <4c5b61b9df6ab33b55f228e1b6579cefad11a9f7 \|\| >=8e5cfe547bf3beeb29d9608be68d22dff2b5012b <ac2ab58a79bf2401ae8c5d1c030bf0a5a376f43a \|\| >=8e5cfe547bf3beeb29d9608be68d22dff2b5012b <4814f28c45f58a71a80d09b80a60da6a063b539a \|\| >=8e5cfe547bf3beeb29d9608be68d22dff2b5012b <b08c3d5ee7feadd821208f7c2c1ec02a16ce5878 \|\| >=8e5cfe547bf3beeb29d9608be68d22dff2b5012b <f63de9054da858d57054474c32464106f8375e0d	4c5b61b9df6ab33b55f228e1b6579cefad11a9f7, ac2ab58a79bf2401ae8c5d1c030bf0a5a376f43a, 4814f28c45f58a71a80d09b80a60da6a063b539a, b08c3d5ee7feadd821208f7c2c1ec02a16ce5878, f63de9054da858d57054474c32464106f8375e0d
Linux/Linuxgeneric	6.3	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to 4c5b61b9df6ab33b55f228e1b6579cefad11a9f7 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Sep 16, 2026

Sources and claim methodology

Upstream source description

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)

Quoted source text, attributed separately from HOL analysis.