CVE-2026-43191

What it actually does

This is a local denial-of-service flaw in the Linux kernel AMD display driver affecting DCN35 display hardware paths. When disabling TMDS output, the driver can turn off the PHY PLL in a way that leaves the output timing generator stuck. That stuck state can prevent DCHVM from acknowledging invalidations when it believes the HUBP remains active but global synchronization is no longer being received. Because the transition to PLL_ON is not atomic, a local thread can be preempted at the wrong time and the IOMMU watchdog may time out, potentially causing a kernel hang or system instability. The impact is availability only; there is no indicated confidentiality or integrity impact.

Why it matters to the business

Affected Linux systems using impacted AMD display hardware may become unresponsive or require reboot, causing workstation, kiosk, VDI, media, or graphics-dependent service disruption. The risk is lower than remotely exploitable flaws because exploitation requires local access and low privileges, EPSS is very low, it is not listed in CISA KEV, and there is no known exploit maturity; however, the operational impact can still be significant where uptime or physical display output is important.

How an attack unfolds

An attacker first needs local access to an affected Linux system with the vulnerable AMD display stack and relevant DCN35/TMDS display path. From that local context, the attacker would trigger display output disable or mode transition behavior that exercises the vulnerable drm/amd/display PHY state transition. If the transition is interrupted or delayed at the wrong point, the PHY PLL can be disabled while other display components still expect synchronization. The OTG can remain stuck, DCHVM invalidation acknowledgements may fail, and the IOMMU watchdog can time out. The practical result is a local availability failure such as a GPU/display hang, kernel stall, or system hang requiring recovery or reboot.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the upstream drm/amd/display fix for the DCN35 PHY FSM transition to TX_EN-to-PLL_ON for TMDS. Because exact fixed package versions were not provided, use distribution advisories and kernel changelogs to identify the first fixed kernel for the affected release stream. Prefer full kernel updates from the OS vendor rather than manually patching display-driver files. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users from interactive desktop sessions, avoiding unnecessary display mode switching on affected systems, disabling unused TMDS/HDMI outputs where operationally feasible, and moving critical workloads away from affected graphics-enabled hosts until patched.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version and that the installed kernel changelog includes the AMD display DCN35 PHY FSM/TMDS PLL transition fix. Reboot into the updated kernel and verify the active kernel with `uname -r` and distribution package tooling. On affected hardware, validate stability by exercising normal display operations such as HDMI/TMDS output enable/disable, monitor hotplug, suspend/resume, and mode changes while watching `dmesg` or journald for AMDGPU, IOMMU, watchdog, OTG, HUBP, or display-core errors. Absence of recurring GPU hangs or IOMMU watchdog timeouts after patching is a practical validation signal.

Typical attack path

1. Obtain local interactive or code execution access to an affected Linux host.
2. Confirm the system uses the AMDGPU display driver with affected AMD DCN35 display hardware and TMDS output paths.
3. Trigger display disable, hotplug, mode-setting, suspend/resume, or output-switching behavior that reaches the vulnerable PHY FSM transition.
4. Cause or wait for a timing window where the transition is not completed atomically before watchdog timeout.
5. System experiences display/GPU/kernel hang or instability, resulting in denial of service.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs, journald, syslog, crash dumps, and GPU/display telemetry for AMDGPU display failures around times of local user activity, display hotplug events, monitor power changes, suspend/resume, or mode switches. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, persistent pstore logs, kdump/vmcore analysis, and endpoint telemetry showing local commands that manipulate displays. Look for repeated hangs or watchdog events involving AMDGPU, DRM display core, IOMMU, OTG, HUBP, DCHVM, global sync, or TMDS/PLL state transitions. Because this vulnerability causes denial of service rather than code execution, there may be no durable malicious artifact beyond logs indicating GPU/display stalls, watchdog timeouts, abrupt reboots, or forced power cycles. Correlate these events with local logins and display-management commands such as `xrandr`, compositor/display settings changes, suspend/resume actions, or monitor connect/disconnect events.

• amdgpu
• drm/amd/display
• IOMMU watchdog
• watchdog timeout
• DCHVM
• HUBP
• OTG
• global sync
• TMDS
• PHY PLL
• PLL_ON
• TX_EN
• GPU hang
• ring gfx timeout
• amdgpu: GPU reset
• amdgpu: failed to reset gpu
• amdgpu: ring .* timeout
• kernel: watchdog: BUG: soft lockup
• kernel: NMI watchdog: Watchdog detected hard LOCKUP
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore/
• /var/crash/

What your security team should do

• Prioritize patching Linux endpoints and systems with AMD GPUs that provide interactive desktop, kiosk, VDI, or graphics-dependent functions.
• Use OS vendor kernel advisories to identify fixed package versions because no universal fixed version is provided for all Linux distributions.
• Inventory affected hosts by locating Linux systems using the `amdgpu` driver and AMD DCN35-class display hardware, especially those with HDMI/TMDS outputs.
• Restrict local access to trusted users until patched, since exploitation requires local privileges.
• Monitor for repeated AMDGPU display hangs, IOMMU watchdog timeouts, and unexplained system freezes as potential exploitation or reliability indicators.
• Do not treat this as a ransomware-prioritized emergency based on current intelligence: it is not in KEV, not known to be used in ransomware, has very low EPSS, and has no known public exploit maturity.