CVE-2026-31461

What it actually does

This vulnerability is a local denial-of-service issue in the Linux kernel AMDGPU display driver. When a display sink is connected and the system resumes, the amdgpu_dm code can overwrite a connector's drm_edid pointer without first freeing the previous allocation. Repeated resume or display reconnect activity can therefore leak kernel memory. Over time, this may exhaust available memory and degrade system stability, potentially causing the graphical stack, kernel subsystems, or the entire host to hang, invoke the OOM killer, or require a reboot. The flaw does not provide confidentiality or integrity impact and is not remotely exploitable based on the published vector; exploitation requires local access and the ability to trigger the affected display/resume path.

Why it matters to the business

Affected Linux systems using AMDGPU display functionality may become unstable or unavailable if kernel memory is repeatedly leaked through display resume or reconnect activity. The most likely operational impact is workstation, kiosk, graphics node, or desktop-session disruption requiring restart or manual recovery. Server impact is generally lower unless AMDGPU display features and suspend/resume workflows are enabled. The CVSS availability impact is high, but EPSS is very low, it is not listed in CISA KEV, there is no known exploit maturity, and no ransomware use is reported, so remediation should be handled through normal kernel patch cycles unless affected systems provide critical graphical services.

How an attack unfolds

An attacker with local access to an affected Linux system targets the AMDGPU display stack. They repeatedly cause the display connector and resume handling path to run, such as by cycling suspend/resume behavior or repeatedly triggering display sink connection state changes where the vulnerable code updates the connector EDID state. Because the previous drm_edid allocation is not freed before being overwritten, each cycle can leak kernel memory. After enough iterations, available memory can be reduced to the point where the system becomes sluggish, processes are killed by the OOM killer, the graphical session fails, or the host requires reboot. There is no indication from the provided information that the issue enables code execution, privilege escalation, data theft, or remote exploitation.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream source that includes the fix for the AMDGPU display drm_edid leak, corresponding to upstream commit 52024a94e7111366141cfc5d888b2ef011f879e5 or its backport. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution to identify the corrected kernel package. After installation, reboot into the patched kernel and remove or deprioritize vulnerable kernels from the bootloader where appropriate. If immediate patching is not possible, reduce exposure by limiting untrusted local interactive access, disabling suspend/resume workflows on affected graphical systems, avoiding repeated display hotplug/reconnect automation, and disabling unused AMDGPU display functionality where operationally feasible. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the AMDGPU drm_edid leak fix. Validate with the distribution package manager and by checking the active kernel after reboot using commands such as uname -a and the vendor's changelog or advisory metadata. Where source provenance is available, confirm the kernel tree includes the change that frees the previous drm_edid before assigning the new value in the amdgpu_dm display code. Functionally, test affected systems by performing normal suspend/resume and display reconnect workflows while monitoring memory usage and kernel logs; patched systems should not show progressive unreclaimed memory growth attributable to repeated AMDGPU display resume events. Also confirm that vulnerable kernels are not still booted by default.

Typical attack path

1. Obtain local access to a Linux system using an affected kernel and AMDGPU display functionality.
2. Confirm the system has an AMD display path where a sink or monitor connection is active.
3. Repeatedly trigger the affected resume and/or display connector update path.
4. Cause the kernel to leak memory each time the vulnerable path overwrites the prior drm_edid allocation.
5. Continue until memory pressure becomes severe enough to degrade availability.
6. Observe system instability, OOM killer activity, graphical failure, hang, or forced reboot.

How to detect it

To assess whether this was already abused or triggered, review host telemetry rather than looking for a unique exploit signature. Relevant sources include kernel logs, system journal, audit logs for suspend/resume activity, desktop power-management logs, GPU/display logs, and endpoint performance telemetry. Look for repeated suspend/resume or display hotplug events followed by steadily increasing memory pressure, OOM killer messages, amdgpu or DRM display messages, graphical session failures, or unexplained reboots. Correlate local user sessions and commands with the onset of memory exhaustion, especially if a non-administrative local user repeatedly initiated suspend/resume, display configuration changes, or monitor reconnect activity. Because this is a memory leak in normal kernel display handling, exploitation may be indistinguishable from accidental triggering unless there is suspicious repetition, timing, or user behavior. There are no known malware artifacts, network indicators, registry keys, or exploit-specific files associated with this issue from the provided information.

• amdgpu
• drm_edid
• Out of memory
• invoked oom-killer
• Killed process
• oom-kill
• Memory allocation failure
• amdgpu_dm
• drm/amd/display
• PM: suspend entry
• PM: suspend exit
• PM: resume
• drm: connector
• GPU reset
• amdgpu: GPU reset
• systemd-suspend
• systemd-logind
• Reached target Sleep
• Started System Suspend
• Finished System Suspend

What your security team should do

• Prioritize patching Linux workstations, kiosks, graphics systems, and shared interactive hosts that use AMDGPU display features and allow local user access.
• Track distribution-specific kernel advisories and deploy the first kernel build that backports the AMDGPU drm_edid leak fix.
• Reboot systems after patching and verify they are actually running the corrected kernel, not only that the package is installed.
• Where patching is delayed, restrict local shell or desktop access to trusted users and disable suspend/resume or repeated display hotplug workflows where feasible.
• Monitor affected systems for unexplained memory exhaustion, OOM killer events, GPU/display resets, or hangs following resume or display reconnect activity.
• Do not treat this as an internet-facing remote-code-execution emergency: current data shows very low EPSS, no KEV listing, no known exploit maturity, and no ransomware association.