CVE-2026-74449

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

The bug is reached during DRM atomic display validation on AMDGPU DCN4.x (dml21 path): userspace ioctl → amdgpu_dm atomic commit → dc_validate_global_state/dc_validate_with_context → dcn401/dcn42_validate_bandwidth → dml2_validate → dml21_validate → dml2_check_mode_supported → dml2_core_calcs_mode_support_ex → calculate_mcache_setting; no network or physical bus is involved.

AC:LAttack complexity, low

An attacker with DRM card access can submit atomic commits that configure DCC-enabled planes and repeatedly probe scaler/viewport edge cases (including degenerate zero-area viewports or zero mvmpg dimensions) to reach calculate_mcache_setting; once triggered, num_mcaches==0 deterministically underflows loop bounds and causes divide-by-zero without races or uncontrollable heap layout.

PR:LPrivileges required, low

Exploitation requires only standard local DRM display privileges to perform atomic modeset ioctl on /dev/dri/card* (typical for session-owning desktop users in the video/render group), not init-namespace root/CAP_SYS_ADMIN; user namespaces do not grant independent access to the host GPU display stack.

UI:NUser interaction, none

No victim interaction is required beyond the attacker issuing their own DRM atomic commit to configure a plane with DCC compression enabled; the kernel panic/corruption occurs during in-kernel DML bandwidth validation, not from another user opening files or mounting filesystems.

S:UScope, unchanged

The vulnerability corrupts kernel memory and can enable local privilege escalation within the same host kernel running the AMDGPU display driver; it does not cross a VM, IOMMU, or sandbox boundary such as KVM guest-to-host escape.

C:HConfidentiality impact, high

When num_mcaches is zero, unsigned underflow in loop bounds (n < *num_mcaches_l - 1) and indexing (mcache_offsets_l[*num_mcaches_l - 1]) performs massive out-of-bounds reads/writes past the fixed-size mcache_offsets arrays in kernel DML state, enabling disclosure of adjacent kernel heap memory rather than a pure crash with no data exposure.

I:HIntegrity impact, high

The same num_mcaches underflow drives unbounded out-of-bounds writes into mode_lib mcache offset arrays and related DML structures during calculate_mcache_setting, providing attacker-influenced kernel memory corruption primitives that could be leveraged for control-flow hijacking beyond a simple denial-of-service fault.

A:HAvailability impact, high

The vulnerable path performs integer divide-by-zero on zero mvmpg_access_width/num_mcaches and executes out-of-bounds mcache offset writes, either of which can immediately trigger a kernel oops or panic during display mode validation, denying service to all users on affected AMD DCN4.x systems until reboot.