Linux Kernel EUVD-2026-82284

Requires local access to trigger the DRM plane atomic-reset path (amdgpu_dm_plane_drm_plane_reset) on a system with an AMD GPU using the amdgpu/DC display driver. The dangling pointer is created ONLY when the kzalloc() for the new plane state fails, i.e., under kernel memory exhaustion - a condition the attacker cannot reliably control, which is why CVSS is AC:H. Limiting factors: local-only vector (no remote/network reach), requires the AMD DC display code path to be present and exercised, requires an allocation failure at a specific point, and provides no confidentiality/integrity primitive - the realistic result is a crash. Systems without AMD GPUs or with the plane reset never exercised are unaffected.

This is a HIGH-CVSS-but-LOW-real-risk issue. The vendor CVSS of 7.0 (AV:L/AC:H/PR:L/UI:N/C:H/I:H/A:H) already reflects local access and high attack complexity, and the C:H/I:H/A:H impact triad is not credible for this bug. The root cause is an allocation-failure error path: amdgpu_dm_plane_drm_plane_reset() frees the old plane state and only then calls kzalloc(); the dangling pointer to freed memory arises ONLY when kzalloc() fails - i.e., under kernel memory exhaustion, which is not directly attacker-controlled. There is no EPSS score, no CISA KEV listing, and no public exploit; the flaw was found by static analysis (Linux Verification Center SVACE), not by observed exploitation. The realistic outcome is a use-after-free/crash (DoS), not confidentiality or integrity compromise. Signals are consistent in direction (local, high-complexity, no exploitation evidence) but the impact metrics are inflated - I assess this materially lower than 7.0. Note also the metadata conflict: the CVE is tagged 'Information Disclosure' yet the mechanism is a dangling-pointer UAF that leads to a crash, so the tag is mislabeled - treat as DoS.

A local user repeatedly triggers DRM plane atomic-reset operations on an AMD GPU while the system is under severe memory pressure, so that a kzalloc() inside the plane reset path fails. The failed allocation leaves the plane state pointer dangling at already-freed memory, and a subsequent access to that state dereferences freed memory, causing a use-after-free crash. No public proof-of-concept exists, and reliably forcing the allocation failure at the exact window is difficult.