CVE-2026-89819 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: validate plane degamma LUT size for private color prop
Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size.
A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces).
The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
A critical vulnerability has been identified within the Linux kernel's display manager subsystem, specifically affecting the Advanced Micro Devices display driver component known as amd/display. This flaw resides in the handling of private color properties associated with individual display planes rather than the entire CRTC output pipeline. The core issue stems from a lack of input validation for the size parameter when processing plane degamma Look-Up Tables. While the system correctly validates LUT sizes for the global CRTC degamma path through the amdgpu_dm_verify_lut_sizes function, this safeguard was entirely absent for per-plane configurations. Consequently, user-supplied data regarding the dimensions of these color transformation tables is passed directly into internal processing functions without any preliminary checks to ensure they conform to expected constraints.
The technical mechanism of exploitation involves manipulating the AMD_PLANE_DEGAMMA_LUT property blob, which allows userspace applications to define custom color correction parameters for specific display planes. When a malformed or undersized LUB entry is submitted, such as one containing only a single data point instead of the required full set, the kernel proceeds with processing it through __set_dm_plane_degamma(). This function forwards the unvalidated size to __is_lut_linear(), where arithmetic operations are performed based on this incorrect value. If the logic determines that the LUT is non-linear, control passes to __drm_lut_to_dc_gamma() via __set_input_tf(). Crucially, this downstream function iterates over a fixed maximum number of entries defined by MAX_COLOR_LUT_ENTRIES, completely ignoring the actual size provided in the input blob. This discrepancy creates two distinct failure modes depending on the specific code path taken during execution.
The operational impact of this vulnerability is severe, manifesting as either a kernel panic due to a divide-by-zero exception or an out-of-bounds memory read that can lead to information disclosure or further exploitation attempts. In scenarios where __is_lut_linear() performs division using the user-controlled size field, providing a value of zero results in immediate fault conditions that crash the system. Alternatively, when processing non-linear LUTs, the iteration over MAX_COLOR_LUT_ENTRIES against an array allocated with significantly fewer elements leads to reading memory beyond the bounds of the intended buffer. This out-of-bounds access can expose sensitive kernel data structures or cause instability within the graphics subsystem. The vulnerability is particularly dangerous because it affects builds where AMD_PRIVATE_COLOR is defined, a configuration often used in production environments requiring advanced color management capabilities for professional displays.
From a classification perspective, this flaw aligns with CWE-125 Out-of-bounds Read and CWE-369 Divide By Zero, reflecting the fundamental errors in input validation and arithmetic safety. In terms of attack vectors, it falls under CWE-20 Improper Input Validation within the context of ATT&CK technique T1059 Command and Scripting Interpreter if leveraged through automated scripts to trigger kernel faults during system operation. The vulnerability highlights a common pattern where security controls are applied inconsistently across different code paths handling similar data types, leading to gaps in defense-in-depth strategies for device drivers.
To mitigate this risk, the resolution involves enforcing strict validation of plane degamma LUT sizes before any processing occurs. Specifically, the kernel now rejects any AMD_PLANE_DEGAMMA_LUT blob whose size does not exactly match MAX_COLOR_LUT_ENTRIES. This approach mirrors the invariant already asserted later in the same function and aligns with the rigorous checks applied to CRTC-level configurations. By ensuring that all LUT inputs conform to the expected fixed-size structure, the system prevents both the arithmetic errors leading to divide-by-zero crashes and the memory access violations resulting from out-of-bounds reads. System administrators should ensure their kernels are updated to include this patch, particularly if they utilize AMD hardware with private color properties enabled in the build configuration. Regular auditing of driver code for similar inconsistencies between CRTC and plane-level validation logic is recommended to prevent analogous vulnerabilities in other subsystems.