CVE-2026-43243

What it actually does

This is a local denial-of-service flaw in the Linux kernel AMD display driver. In the DCN 4.0.1 display code path, the driver can attempt to access a link encoder object for a DPIA link without first validating the signal type. On affected systems using AMD graphics/display functionality, a low-privileged local user or local process that can trigger the vulnerable display configuration path may cause a kernel crash, resulting in loss of system availability. The vulnerability does not directly provide confidentiality or integrity impact based on the supplied scoring and description.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting user workstations, graphics-enabled servers, kiosks, VDI hosts, or other systems dependent on AMD display hardware. The risk is primarily operational disruption rather than data theft. The low EPSS score and absence from CISA KEV indicate no known broad exploitation at this time, but the bug has been public for 97 days, so organizations with exposed multi-user Linux systems or AMD GPU/display fleets should still prioritize normal kernel maintenance.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient privileges to interact with display-related functionality. The attacker then causes the AMD display driver to process a DPIA link through the vulnerable DCN 4.0.1 clock-source selection path. Because the driver fails to verify the signal type before accessing the link encoder, the kernel can dereference an invalid or unexpected object and crash. The practical result is a local denial of service: the machine may panic, reboot, hang, or lose display/session availability. There is no indication from the provided information that this vulnerability enables code execution, privilege escalation, or data disclosure.

How to fix it

Update the Linux kernel to a version that includes the upstream AMD display fix adding the signal type check in drm/amd/display for dcn401 get_phyd32clk_src. Because no exact fixed versions were provided, use the security advisories and kernel packages from the relevant Linux distribution or vendor and confirm the patch for CVE-2026-43243 is included. If immediate patching is not possible, reduce risk by limiting local interactive access to affected systems, restricting untrusted users from multi-user graphics hosts, disabling or avoiding affected AMD display paths where operationally feasible, and prioritizing patching on systems with AMD GPUs, display-attached workloads, VDI, kiosk, or shared desktop use cases.

How to confirm the fix worked

Confirm the running kernel version has been updated to a vendor build that includes the AMD display fix for this vulnerability. Validate by checking the distribution security advisory, package changelog, or kernel source/package notes for the drm/amd/display dcn401 get_phyd32clk_src signal type check. After patching, reboot into the fixed kernel and verify with standard commands such as uname -r and the platform package manager. Review dmesg, journalctl, or kernel logs after normal display activity to ensure there are no recurring amdgpu, drm/amd/display, get_phyd32clk_src, kernel oops, or panic messages. Where feasible, test representative display attach/detach, docking, multi-monitor, and USB-C/DisplayPort-related workflows on patched systems to confirm stability.

Typical attack path

1. Obtain local authenticated access to an affected Linux system using the AMD display driver.
2. Identify or trigger a display configuration path involving AMD DCN 4.0.1 display handling and a DPIA link.
3. Cause the vulnerable get_phyd32clk_src logic to execute without the necessary signal type check.
4. Trigger invalid access to the link encoder object.
5. Cause a kernel oops, panic, hang, reboot, or display/session outage.

How to detect it

Look for signs of prior local denial-of-service activity rather than network compromise. Relevant sources include kernel logs, system journal, crash dump infrastructure, panic/oops records, reboot history, endpoint telemetry, and helpdesk or monitoring records for unexplained hangs or reboots. Search for kernel oops or panic messages involving amdgpu, drm/amd/display, dcn401, or get_phyd32clk_src, especially when correlated with local user sessions, display attach/detach events, docking activity, or repeated crashes on AMD graphics systems. Because this is a crash-class local vulnerability and no public exploit artifacts are indicated, absence of a unique exploit string does not prove non-exploitation. Treat repeated unexplained crashes in the AMD display stack on unpatched systems as suspicious and preserve crash dumps for kernel backtrace analysis.

• get_phyd32clk_src
• dcn401
• drm/amd/display
• amdgpu
• BUG: kernel NULL pointer dereference
• Oops:
• kernel panic - not syncing
• Call Trace:
• RIP:
• /var/crash/
• /var/lib/systemd/coredump/
• journalctl -k

What your security team should do

• Inventory Linux systems using AMD GPUs or the amdgpu/display stack, especially shared workstations, VDI hosts, kiosks, engineering desktops, and graphics-enabled servers.
• Patch affected systems through the appropriate Linux distribution or vendor kernel update channel and reboot into the fixed kernel.
• Prioritize systems with multiple local users or untrusted local workloads, because exploitation requires local access but can cause full system outage.
• Monitor kernel logs for amdgpu, drm/amd/display, dcn401, get_phyd32clk_src, kernel oops, panic, or unexpected reboot events until patch coverage is complete.
• Restrict local shell, desktop, and workload access on unpatched systems to trusted users only.
• If patching is delayed, consider operational mitigations such as disabling affected AMD display functionality or avoiding risky display/docking workflows where feasible.
• Track vendor advisories for exact fixed kernel package versions because no fixed version list was provided in the input.