CVE-2026-90035 in Linux
Summary
by MITRE • 09/16/2026
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)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for AMD display hardware, specifically within the DRM subsystem's amdgpu component, contained a critical arithmetic vulnerability in the function get_estimated_bw. This routine is responsible for calculating estimated bandwidth requirements for DisplayPort tunneling scenarios, particularly those involving USB4 and DPIA protocols. The core technical flaw lies in an unprotected division operation where the divisor is link->dpia_bw_alloc_config.bw_granularity. Under normal operational sequences, this granularity value is initialized to zero by reset_bw_alloc_struct() during structure initialization or reset phases. It is subsequently populated with a valid non-zero integer only after the system processes a DP_TUNNELING_BW_ALLOC_CAP_CHANGED event, which signals that the connected device has advertised its bandwidth allocation capabilities. However, the interrupt handler link_dp_dpia_handle_bw_alloc_status(), which responds to DPCD interrupts indicating changes in estimated bandwidth status (DP_TUNNELING_ESTIMATED_BW_CHANGED), invokes get_estimated_bw() without verifying whether the capability change event had previously occurred for that specific link.
This logical sequencing error creates a race condition or state mismatch where an external device, such as a USB4 dock or tunneling peripheral, can trigger an estimated bandwidth update interrupt before it has ever reported its allocation capabilities. When this out-of-order sequence occurs, the bw_granularity field remains at its initial zeroed value. Consequently, when get_estimated_bw() attempts to perform the division by this uninitialized parameter, a divide-by-zero exception is triggered within the kernel space. In Linux kernel development, such arithmetic errors typically result in an immediate crash of the affected CPU core or the entire system, manifesting as a Kernel Panic or Oops message that halts all operations and requires a hard reset to recover. This represents a significant availability impact, allowing any connected device with appropriate firmware behavior to cause local denial of service through simple hardware interaction without requiring authentication or prior exploitation steps beyond physical connection.
From a vulnerability classification perspective, this issue aligns closely with CWE-369, which describes Divide By Zero errors in software systems. The root cause is fundamentally an improper check for unusual or exceptional input conditions, specifically failing to validate that the divisor is non-zero before execution of the arithmetic operation. In terms of attack vectors and tactical mapping under the MITRE ATT&CK framework, this vulnerability facilitates Local Denial of Service (T1499). An attacker with physical access to the system could exploit this by connecting a malicious or specifically crafted USB4 device that sends bandwidth change interrupts prior to capability negotiation, thereby crashing the host machine. While remote exploitation is not applicable due to the hardware dependency, local privilege escalation may be indirectly possible if an unprivileged user can trigger the condition and subsequently leverage other kernel vulnerabilities for code execution, though the primary impact remains system instability.
The remediation strategy implemented in this fix involves adding a defensive guard clause within link_dp_dpia_handle_bw_alloc_status() or ensuring get_estimated_bw is only called when valid state exists. The solution mirrors existing safeguards already present in link_dpia_send_bw_alloc_request(), which correctly checks the bw_granularity value before performing similar divisions. This consistency not only resolves the immediate crash but also reinforces a robust pattern for handling bandwidth allocation states across different parts of the driver codebase. To mitigate this risk, system administrators and developers must ensure that the Linux kernel is updated to include this patch. For end-users, avoiding untrusted or non-compliant USB4 peripherals until updates are applied can reduce exposure, although the most effective mitigation remains timely application of vendor-provided security patches for the graphics driver stack.