CVE-2026-64219

What it actually does

This flaw is a local Linux kernel memory-safety vulnerability in the AMD display driver path for asynchronous DisplayPort AUX transfers. The vulnerable function copies an attacker-influenced payload length into a fixed 16-byte stack buffer while relying on an assertion that is not enforced in production builds. If a caller reaches this code path with a payload length greater than 16 bytes, the kernel can overwrite adjacent stack memory. The same function also uses a link_index value to access the dc->links array without first confirming that the index is within dc->link_count, creating an out-of-bounds access risk. Successful exploitation could lead to kernel memory corruption, system crash, information disclosure, or potentially local privilege escalation, although the CVSS vector indicates exploitation requires local access, low privileges, no user interaction, and high attack complexity.

Why it matters to the business

Systems using affected Linux kernels with AMD display functionality may be exposed to a local kernel compromise or denial-of-service condition. In practical terms, an attacker who already has a low-privileged local foothold could potentially crash the system or attempt to gain higher privileges, increasing the impact of otherwise limited account compromise. Because this is a kernel issue, successful exploitation can undermine host isolation, endpoint trust, and workload integrity. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so immediate internet-scale exploitation is unlikely; however, kernel privilege-escalation bugs remain important to patch during standard OS maintenance windows.

How an attack unfolds

An attacker first needs local code execution on a Linux system running an affected kernel with the vulnerable AMD display driver code present and reachable. From that foothold, the attacker attempts to trigger the AMD display DisplayPort AUX transfer handling path with crafted input that causes dc_process_dmub_aux_transfer_async() to receive a payload length greater than the 16-byte dpaux.data buffer, or a link_index outside the valid link array range. In vulnerable builds, the length check is only an ASSERT and is not enforced at runtime, so the memcpy operation can corrupt stack memory. Depending on kernel configuration, compiler protections, hardware state, and exact call path control, this may produce a kernel oops/panic, leak or corrupt kernel memory, or support a more complex privilege-escalation chain. Exploitation is expected to be non-trivial because it requires local access and reliable control over a hardware/display-driver-specific kernel path.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for drm/amd/display in dc_process_dmub_aux_transfer_async(), specifically the patch that replaces the payload-length ASSERT with a hard runtime length check and validates link_index against dc->link_count before dereferencing dc->links. Where distribution kernels are used, apply the vendor-provided kernel security update rather than attempting to cherry-pick manually. Reboot systems after kernel installation to ensure the fixed kernel is running. If immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, disabling or avoiding affected AMD display functionality where operationally feasible, and prioritizing monitoring for kernel crashes or abnormal amdgpu/DRM activity. No fixed package versions were provided in the input, so administrators should consult their Linux distribution or kernel vendor advisories for the exact corrected kernel build.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, contains the fix. Check the active kernel with uname -r and compare it to the distribution advisory for this vulnerability. For source-based or custom kernels, confirm the AMD display driver code includes a runtime check rejecting payload lengths larger than sizeof(dpaux.data) and a bounds check ensuring link_index is less than dc->link_count before using dc->links[link_index]. Validate that systems were rebooted into the fixed kernel after patching. Exposure can be assessed by checking whether the amdgpu driver is present or loaded and whether the kernel build includes the affected drm/amd/display code path. Review dmesg, journalctl, and kernel crash logs for recent amdgpu, DRM, stack corruption, kernel oops, or panic messages before and after remediation.

Typical attack path

1. Obtain low-privileged local code execution on a Linux host using an affected kernel.
2. Confirm the vulnerable AMD display driver path is loaded or reachable, commonly through amdgpu/DRM display functionality.
3. Interact with a user-space or kernel-exposed interface that can cause asynchronous DMUB AUX transfer processing.
4. Supply crafted transfer parameters that result in a payload length greater than 16 bytes or an invalid link_index.
5. Trigger the vulnerable memcpy or out-of-bounds link access in dc_process_dmub_aux_transfer_async().
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation to kernel/root context.

How to detect it

Look for evidence of attempted or successful exploitation in kernel and system logs rather than relying on network indicators, because this is a local kernel driver issue. Review journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, and endpoint telemetry for kernel oops, panic, stack corruption, KASAN, UBSAN, or general protection fault events involving amdgpu, DRM, DMUB, AUX transfer handling, or dc_process_dmub_aux_transfer_async. Pay particular attention to crashes shortly after local user activity, GPU/display probing, monitor hot-plug activity, or execution of unusual local programs that interact with DRM, DisplayPort, or graphics device nodes. If kernel crash dumps are available, inspect stack traces for drm/amd/display functions and memory corruption near dpaux.data handling. Also review audit logs and EDR process telemetry for untrusted users running custom binaries that access /dev/dri/*, graphics ioctls, or display-management interfaces shortly before a kernel fault. There are no known threat actors or public exploitation campaigns provided for this vulnerability, so detection should focus on host-based forensic artifacts and anomalous local activity rather than named-campaign indicators.

• dc_process_dmub_aux_transfer_async
• drm/amd/display
• amdgpu
• DMUB
• AUX transfer
• dpaux.data
• link_index
• stack buffer overflow
• stack smashing detected
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• KASAN: stack-out-of-bounds
• KASAN: slab-out-of-bounds
• BUG: unable to handle kernel paging request
• /dev/dri/card0
• /dev/dri/renderD128
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/vmcore
• ba4caa9fecdf7a38f98c878ad05a8a64148b6881

What your security team should do

• Prioritize patching Linux endpoints and workstations using AMD GPUs or affected AMD display functionality, especially multi-user systems where untrusted local users can execute code.
• Track vendor kernel advisories and deploy the fixed distribution kernel as soon as available; reboot to activate it.
• Inventory systems with loaded amdgpu/DRM display drivers and rank them ahead of systems without AMD display hardware or driver exposure.
• Restrict local interactive access on unpatched systems to trusted administrators only until remediation is complete.
• Monitor kernel logs and crash telemetry for amdgpu, DRM, stack-buffer-overflow, kernel oops, panic, or KASAN reports that mention dc_process_dmub_aux_transfer_async or DMUB AUX handling.
• For custom kernel builds, ensure the upstream patch associated with commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881 or its equivalent has been applied.
• Do not treat the low EPSS score as a reason to ignore the issue; local kernel privilege-escalation vulnerabilities are commonly useful after initial compromise.