CVE-2026-43320

What it actually does

This is a local denial-of-service flaw in the Linux kernel AMD display driver. The vulnerable code path in drm/amd/display can use a Display Stream Compression/eDP-related function hook without first confirming that the hook is present. On affected systems with AMD display hardware and the vulnerable kernel code, a local user who can trigger the relevant display configuration path may cause a NULL function pointer dereference or similar kernel fault, resulting in a kernel oops, display subsystem failure, or full system crash. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and impact limited to availability.

Why it matters to the business

Successful exploitation can crash affected Linux workstations, laptops, kiosks, or other systems using AMD display hardware, causing downtime, interrupted user sessions, data loss from unsaved work, and operational disruption. Because exploitation requires local authenticated access and there is no known public exploitation or KEV listing, broad internet-scale risk is low; however, systems that provide shell access, shared desktops, lab access, developer workstations, or multi-user Linux environments should treat the issue as a stability and abuse-risk concern.

How an attack unfolds

An attacker first obtains local, low-privileged access to an affected Linux system with the vulnerable AMD display driver code path present. They then invoke or manipulate display configuration behavior that reaches the DSC/eDP handling path in drm/amd/display. Because the kernel code fails to verify that a required function hook exists before calling it, the crafted or unusual display state can cause the kernel to dereference an invalid or missing hook. The result is a kernel fault that may crash the display stack or panic the host, producing a denial of service. There is no indication from the provided intelligence that this vulnerability enables privilege escalation, data theft, remote compromise, ransomware deployment, or active exploitation by named threat actors.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream drm/amd/display fix for the missing function-hook check. No exact fixed package versions were provided in the input, so administrators should consult their distribution advisories and kernel changelogs for CVE-2026-43320 or the AMD display DSC/eDP hook-check fix. Where immediate patching is not possible, reduce exposure by limiting local shell access to affected systems, restricting untrusted users from interactive graphical sessions, avoiding shared multi-user use on affected AMD display systems, and prioritizing reboot into a patched kernel once available. Kernel live patching may not cover display-driver changes on all platforms, so verify whether a reboot is required by the vendor.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the vendor-fixed release and that the system has rebooted into the updated kernel, not merely installed it. Review distribution security advisories, package changelogs, or kernel commit history for the drm/amd/display DSC eDP hook-check fix. On Linux systems, compare the running kernel from `uname -r` with installed kernel packages and vendor advisory fixed versions. For exposure validation, identify systems using AMD display drivers by checking loaded modules and kernel logs for amdgpu/drm activity, then prioritize those systems for patching. After remediation, monitor for absence of recurring kernel oops, panic, GPU reset, or drm/amd/display fault messages during display mode changes, suspend/resume, docking, or external display events.

Typical attack path

1. Gain local access to an affected Linux system, such as through a normal user account, shared workstation access, or another foothold.
2. Confirm the system is running a vulnerable Linux kernel with AMD display driver support and relevant eDP/Display Stream Compression code paths.
3. Trigger display configuration or mode-setting behavior that reaches the vulnerable drm/amd/display DSC eDP hook path.
4. Cause the driver to call an unchecked missing function hook, resulting in a kernel oops, display failure, or system crash.
5. Repeat the trigger to sustain disruption until the kernel is patched or the vulnerable code path is otherwise mitigated.

How to detect it

To determine whether the issue may have already been exploited or triggered, review kernel and system logs for crashes involving the AMD display stack. Useful sources include `dmesg`, journald entries from `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps from kdump, apport/ABRT reports, and monitoring alerts for unexpected reboots or kernel panics. Focus on events involving `amdgpu`, `drm`, `drm/amd/display`, Display Core, DSC, eDP, NULL pointer dereferences, general protection faults, kernel oops messages, GPU resets, or repeated display mode-setting failures. Correlate crash timestamps with local user logins, graphical session starts, display hotplug/docking events, suspend/resume cycles, or commands that alter display configuration. There are no known threat-actor-specific indicators, network indicators, malware artifacts, or ransomware associations for this vulnerability based on the provided data.

• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• general protection fault
• RIP: 0010:
• amdgpu
• drm/amd/display
• [drm]
• Display Core
• DCN
• DSC
• eDP
• GPU reset
• amdgpu: GPU reset
• amdgpu_device_gpu_recover
• flip_done timed out
• drm_atomic_helper_wait_for_flip_done
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• journalctl -k

What your security team should do

• Prioritize patching Linux endpoints and shared systems with AMD graphics hardware, especially multi-user workstations, kiosks, lab machines, developer desktops, and systems where untrusted users have local access.
• Track vendor advisories for the exact fixed kernel package versions because no fixed versions were supplied in the source data.
• Ensure patched kernels are actually running by scheduling required reboots and validating `uname -r` after maintenance.
• Monitor kernel logs for crashes or oops events involving drm/amd/display, amdgpu, DSC, eDP, or display mode-setting paths.
• Restrict local interactive access on affected systems until patched if the system has high availability requirements.
• Do not treat this as a remote-code-execution or data-exfiltration issue based on current intelligence; focus response on availability risk, patch validation, and crash forensics.
• Because EPSS is very low and there is no KEV listing or known exploit maturity, sequence remediation after externally exploitable critical issues, unless the affected systems are operationally sensitive or broadly shared.