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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The bug is reached only through local DRM ioctls (DRM_IOCTL_MODE_CREATEPROPBLOB then DRM_IOCTL_MODE_ATOMIC or MODE_OBJ_SETPROPERTY) on /dev/dri/cardN when setting AMD_PLANE_DEGAMMA_LUT, a private plane property on AMDGPU display; no network or remote-peer path exists into amdgpu_dm color management.
AC:L - The attacker fully controls the LUT blob size and contents and can deterministically trigger a divide-by-zero with a one-entry blob or a large heap over-read with a short non-linear LUT; no race, memory-layout luck, or victim state is required.
PR:L - DRM_IOCTL_MODE_ATOMIC requires DRM master, which is the normal state of the logged-in graphical-session user (compositor, gamescope, kiosk, Steam Deck, Android) or the first opener of an unclaimed card; no CAP_SYS_ADMIN or real root is needed.
UI:N - The attacker creates the undersized blob and issues the atomic commit from their own process; no other user must open a file, plug in a display, or take any action.
S:U - The divide-by-zero and out-of-bounds read occur in kernel context on the same host inside the amdgpu display driver; impact stays within the kernel security authority with no VM, IOMMU, or sandbox boundary crossed.
C:H - __drm_lut_to_dc_gamma() always walks MAX_COLOR_LUT_ENTRIES (4096) drm_color_lut records regardless of blob length, over-reading about 32KB of adjacent kernel heap from a short LUT blob and copying those values into dc_gamma and the display pipeline.
I:H - Kernel heap contents from the over-read are stored into dc_gamma entries and applied by apply_lut_1d() into the plane transfer function that is programmed into DPP degamma hardware, corrupting driver and GPU color-management state with unvalidated memory.
A:H - A one-entry LUT causes a divide-error (#DE) panic in __is_lut_linear(); a short non-linear LUT makes __drm_lut_to_dc_gamma() walk tens of kilobytes past the blob into potentially unmapped heap, oopsing the kernel on the atomic check/commit path.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only through local DRM ioctls (DRM_IOCTL_MODE_CREATEPROPBLOB then DRM_IOCTL_MODE_ATOMIC or MODE_OBJ_SETPROPERTY) on /dev/dri/cardN when setting AMD_PLANE_DEGAMMA_LUT, a private plane property on AMDGPU display; no network or remote-peer path exists into amdgpu_dm color management.
AC:L - The attacker fully controls the LUT blob size and contents and can deterministically trigger a divide-by-zero with a one-entry blob or a large heap over-read with a short non-linear LUT; no race, memory-layout luck, or victim state is required.
PR:L - DRM_IOCTL_MODE_ATOMIC requires DRM master, which is the normal state of the logged-in graphical-session user (compositor, gamescope, kiosk, Steam Deck, Android) or the first opener of an unclaimed card; no CAP_SYS_ADMIN or real root is needed.
UI:N - The attacker creates the undersized blob and issues the atomic commit from their own process; no other user must open a file, plug in a display, or take any action.
S:U - The divide-by-zero and out-of-bounds read occur in kernel context on the same host inside the amdgpu display driver; impact stays within the kernel security authority with no VM, IOMMU, or sandbox boundary crossed.
C:H - __drm_lut_to_dc_gamma() always walks MAX_COLOR_LUT_ENTRIES (4096) drm_color_lut records regardless of blob length, over-reading about 32KB of adjacent kernel heap from a short LUT blob and copying those values into dc_gamma and the display pipeline.
I:H - Kernel heap contents from the over-read are stored into dc_gamma entries and applied by apply_lut_1d() into the plane transfer function that is programmed into DPP degamma hardware, corrupting driver and GPU color-management state with unvalidated memory.
A:H - A one-entry LUT causes a divide-error (#DE) panic in __is_lut_linear(); a short non-linear LUT makes __drm_lut_to_dc_gamma() walk tens of kilobytes past the blob into potentially unmapped heap, oopsing the kernel on the atomic check/commit path.
CVSS 3.1