CVE-2026-90289

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

hdcp_update_display() and update_config() index hdcp_workqueue.aconnector[] with aconnector->base.index from drm_connector_init_only()'s ida_alloc_max(..., 31). The path is DRM_IOCTL_MODE_ATOMIC → drm_mode_atomic_ioctl → amdgpu_dm_atomic_commit_tail → amdgpu_dm_update_hdcp()/update_psp_stream_config(); dm_dp_mst_get_modes() is reached from DRM_IOCTL_MODE_GETCONNECTOR. The index is kernel-assigned, not a protocol field.

AC:LAttack complexity, low

No race or layout lottery: drm_connector_init_only() can assign index 31, and dm_dp_add_mst_connector() creates MST connectors until that id is used. A DRM-master atomic commit that enables that connector calls update_config(), which does hdcp_w->aconnector[conn_index] with no bounds check. hdcp_create_workqueue() is created by default on Raven-and-later GPUs.

PR:LPrivileges required, low

drm_mode_atomic_ioctl and drm_mode_obj_set_property_ioctl are DRM_MASTER in drm_ioctl.c; drm_mode_getconnector() only calls fill_modes when drm_is_current_master(). logind grants DRM master to the seated unprivileged video/render-group user on typical AMDGPU desktops, laptops, and cloud GPU instances, so init-namespace root is not required.

UI:NUser interaction, none

The DRM-master attacker triggers the OOB with their own DRM_IOCTL_MODE_ATOMIC (stream enable through update_psp_stream_config(), or Content Protection via amdgpu_dm_update_hdcp()) on the index-31 connector; no other user must mount media, open a file, or attach a display on the attacker's behalf.

S:UScope, unchanged

aconnector[31] overwrites the following hdcp_workqueue.mutex in the same host-kernel AMDGPU HDCP object; the corruption and any oops stay inside that kernel authority and do not cross a KVM/Xen, IOMMU, or sandbox boundary.

C:HConfidentiality impact, high

hdcp_update_display() holds hdcp_w->mutex then reads aconnector[31], which overlays mutex.owner (the locked task_struct *). A non-NULL owner is treated as amdgpu_dm_connector * and drm_connector_put(&...->base) follows it. dm_dp_mst_get_modes() also copies hdcp_content_type[31]/content_protection[31] into connector state readable via GETCONNECTOR.

I:HIntegrity impact, high

hdcp_update_display() and update_config() write aconnector[31]=aconnector, storing an amdgpu_dm_connector * over mutex.owner while the lock is held. amdgpu_dm_update_hdcp() also writes hdcp_content_type[connector->index] and content_protection[connector->index] on MST. That is an out-of-bounds write into adjacent hdcp_workqueue fields.

A:HAvailability impact, high

drm_connector_put() on mutex.owner type-confused as amdgpu_dm_connector, and later lock operations on a mutex whose owner was replaced by a connector pointer, oops or panic the kernel in amdgpu_dm_atomic_commit_tail/HDCP workqueue paths.