CVE-2026-43305

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel AMD display driver. A mismatch in the logic used to acquire and release the DMUB hardware lock can cause the driver to attempt an incorrect unlock path when the hardware fast path is used on AMD ASICs without FAMS support. The result can be a kernel or graphics stack hang that impacts system availability. The issue does not directly provide confidentiality or integrity impact and requires local low-privileged access.

Why it matters to the business

Successful exploitation can freeze or hang affected Linux systems using impacted AMD display hardware, disrupting user workstations, kiosks, GPU-enabled endpoints, or other systems that rely on stable graphical output. The risk is primarily operational availability rather than data theft. The vulnerability is not listed in CISA KEV, has no known ransomware association, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, systems with shared local access or untrusted local users should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with a vulnerable kernel and compatible AMD display hardware. From a low-privileged account, the attacker triggers graphics or display operations that exercise the AMD display hardware sequencing fast path. On affected ASICs without FAMS support, the driver may decide differently about whether the DMUB hardware lock was used versus whether it should be unlocked. That mismatched lock handling can leave the display stack or kernel in a hung state, causing denial of service until the system is recovered, restarted, or otherwise remediated. There is no indication from the provided intelligence that exploitation enables code execution, privilege escalation, or data access.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the AMD display driver DMUB hardware-lock mismatch. Because no fixed versions were provided in the input, rely on distribution security advisories, kernel changelogs, or vendor backport notes for the exact package version. Where immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, restricting use of affected graphical sessions on shared systems, disabling or avoiding affected AMD display paths where operationally feasible, or booting into a known unaffected kernel. Mitigations should be treated as temporary because the durable fix is the corrected kernel driver logic that uses the same stored flag for both lock and unlock decisions.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the AMD display driver fix for the DMUB HW lock mismatch. Check the active kernel version with standard platform tooling such as uname and the distribution package manager, then compare it against the vendor advisory or changelog that references the fix. On source-based or custom kernels, confirm the drm/amd/display change is present and that the driver uses a single stored flag to determine both lock acquisition and unlock. After patching and rebooting into the fixed kernel, validate system stability by exercising normal graphical workloads, display mode changes, suspend/resume if applicable, and compositor activity while monitoring kernel logs for amdgpu, drm, DMUB, GPU reset, or hang messages.

Typical attack path

1. Gain local low-privileged access to an affected Linux system.
2. Confirm or assume the system is running a vulnerable Linux kernel with the AMD display driver and impacted AMD display hardware.
3. Trigger display, modeset, graphics, or compositor activity that reaches the AMD display HWSS fast path.
4. Cause the DMUB hardware-lock acquire/unlock mismatch on hardware without FAMS support.
5. Induce a graphics stack or system hang, resulting in local denial of service.

How to detect it

Determining whether this was already exploited is difficult because the expected outcome is a hang rather than a durable payload, new account, or distinctive malware artifact. Review historical kernel logs, system journals, crash dumps, watchdog records, GPU reset telemetry, and availability monitoring around unexplained freezes or forced reboots on Linux systems with AMD display hardware. Useful log sources include journald, syslog, kern.log, dmesg captures, crash dump infrastructure such as kdump, endpoint telemetry, and system uptime/reboot records. Look for amdgpu or drm messages immediately before hangs, especially references to DMUB, display core, hardware sequencing, GPU reset attempts, ring timeouts, page flips, modesets, compositor activity, or watchdog-triggered resets. Correlate events with local user sessions, graphical workload launches, display reconfiguration, suspend/resume cycles, or repeated failures caused by the same user or process. Absence of these artifacts does not rule out exploitation because a hard hang may prevent logs from being flushed to disk.

• amdgpu
• drm/amd/display
• DMUB
• dmub
• GPU reset
• ring gfx timeout
• ring timeout
• amdgpu: GPU reset
• amdgpu: ring
• drm:amdgpu
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• kernel: BUG: soft lockup
• kernel: hung task
• blocked for more than
• drm/amd/display:
• HWSS
• FAMS

What your security team should do

• Inventory Linux systems using AMD GPUs or AMD display hardware and identify those running affected kernel builds.
• Prioritize patching shared workstations, multi-user Linux systems, developer desktops, VDI endpoints, kiosks, and systems where untrusted users can run local code.
• Apply vendor kernel updates and reboot systems into the fixed kernel; confirm old vulnerable kernels are not still the active boot target.
• If patching is delayed, limit local access to trusted users and consider operational workarounds such as avoiding affected graphical workloads or using an unaffected kernel branch.
• Monitor kernel and system logs for amdgpu, drm, DMUB, GPU reset, display hang, or watchdog events that may indicate attempted triggering or recurring instability.
• Because KEV status is false, ransomware association is false, EPSS is very low, and exploit maturity is none, handle this as a reliability and local-denial-of-service patching priority rather than an emergency remote-compromise event unless the affected systems are business-critical or exposed to untrusted local users.