CVE-2026-43206

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the AMD KFD component of the DRM/AMDGPU driver. The vulnerable kfd_event_page_set() path clears a fixed-size event page region using memset for KFD_SIGNAL_EVENT_LIMIT * 8 bytes without first validating that the caller-provided buffer is large enough. A local unprivileged user with access to the affected KFD interface can supply an undersized buffer and cause an out-of-bounds write in kernel memory. Successful exploitation can corrupt adjacent kernel memory and may allow privilege escalation to root, kernel code execution, information disclosure, or system crash.

Why it matters to the business

Systems using affected Linux kernels with the AMD GPU KFD/AMDGPU stack exposed are at risk of local privilege escalation. An attacker who already has a low-privileged account, shell, compromised application process, or container with access to the relevant GPU device can potentially gain full control of the host. This can lead to data theft, tampering, disabling security controls, lateral movement, or service disruption. EPSS is currently very low and there is no KEV listing or known exploit maturity, but the CVSS score is high because kernel privilege escalation flaws can become highly valuable once a reliable exploit is developed.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system running an affected kernel and the AMD KFD/AMDGPU driver. They verify that the KFD device interface is present and accessible, commonly through /dev/kfd or GPU compute-related permissions. The attacker then invokes the vulnerable KFD event-page operation with a deliberately undersized userspace-backed buffer. Because the kernel path writes a fixed KFD_SIGNAL_EVENT_LIMIT * 8 byte region without checking the supplied buffer size, the write extends beyond the intended object and corrupts nearby kernel memory. With careful heap shaping, repeated attempts, and kernel-version-specific exploitation, the attacker may turn the corruption into privilege escalation, gaining root-level capabilities or disabling kernel protections. Less reliable exploitation may instead cause a kernel panic or GPU driver instability.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the amdkfd kfd_event_page_set() bounds-checking issue. Because no exact fixed versions were provided, use the latest security-supported kernel from the operating system or appliance vendor and confirm that the vendor advisory explicitly includes the fix for CVE-2026-43206 or the related drm/amdkfd patch. If immediate patching is not possible, reduce exposure by restricting access to /dev/kfd and GPU compute device nodes to only trusted users and workloads, disabling or unloading AMDGPU/KFD functionality where it is not required, preventing untrusted containers from accessing GPU devices, and enforcing least-privilege device cgroup and udev rules. Reboot after kernel updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel version is affected according to the Linux distribution or vendor advisory and whether AMDGPU/KFD is in use. Validate remediation by confirming the host has booted into a patched kernel, the vulnerable module code has been replaced, and the relevant vendor package version is no longer listed as vulnerable. Check loaded modules with tools such as lsmod for amdgpu and confirm whether /dev/kfd exists and what users or groups can access it. Where source or debug symbols are available, verify that the kfd_event_page_set() implementation includes a buffer-size check before the fixed-size memset. For mitigation validation, confirm untrusted users and containers cannot open /dev/kfd or related GPU device nodes.

Typical attack path

1. Gain local execution on a Linux host through a low-privileged account, compromised service, SSH access, container escape prerequisite, or malicious workload.
2. Check whether the host is running an affected Linux kernel with the AMD KFD/AMDGPU driver loaded and whether /dev/kfd or related GPU device nodes are accessible.
3. Trigger the vulnerable KFD event-page handling path using a crafted request that provides a smaller buffer than the kernel assumes.
4. Cause an out-of-bounds kernel memory write during the kfd_event_page_set() memset operation.
5. Use heap grooming and repeated triggering to corrupt security-relevant kernel structures or credentials.
6. Escalate privileges to root or kernel-level execution, or cause a denial of service if exploitation is unstable.
7. Use elevated privileges to persist, access sensitive data, disable defenses, or move laterally.

How to detect it

To determine whether exploitation may already have occurred, review host telemetry and kernel logs for evidence of abnormal AMD KFD/AMDGPU activity, kernel memory corruption, GPU driver crashes, or privilege changes following access to /dev/kfd. Useful sources include auditd logs for /dev/kfd opens, syslog/journald, dmesg, kernel panic logs, EDR process telemetry, sudo/su/auth logs, container runtime logs, and GPU workload scheduler logs. Look for non-root or unexpected service accounts interacting with /dev/kfd shortly before kernel warnings, KASAN reports, oopses, BUG messages, general protection faults, or sudden privilege escalation events. Since no public exploit maturity or threat actors are reported, detection should focus on behavioral signs rather than known malware signatures. Correlate suspicious /dev/kfd access with new root-owned files, unexpected setuid binaries, disabled security agents, new kernel modules, unusual shells, or authentication anomalies.

• /dev/kfd
• amdgpu
• amdkfd
• kfd_event_page_set
• drivers/gpu/drm/amd/amdkfd
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• BUG: KASAN: use-after-free
• kernel BUG at drivers/gpu/drm/amd/amdkfd
• general protection fault
• unable to handle kernel paging request
• Oops:
• kernel panic
• drm/amdkfd
• KFD_SIGNAL_EVENT_LIMIT

What your security team should do

• Prioritize patching Linux systems that use AMD GPUs for compute, graphics, VDI, AI/ML, rendering, shared HPC, CI/CD, or multi-user workloads.
• Inventory systems where amdgpu is loaded or /dev/kfd exists, then map which users, containers, and services can access the device.
• Apply the latest vendor-supported kernel security update and reboot into the patched kernel; do not rely on package installation alone without a reboot.
• Restrict /dev/kfd and related GPU device node permissions to trusted users only, especially on shared servers and container platforms.
• Remove GPU device passthrough from untrusted containers or workloads until patched.
• Increase monitoring for local privilege escalation behavior on affected systems, including crashes in amdkfd/amdgpu paths, suspicious access to /dev/kfd, and unexpected root shells spawned by non-root users.
• Because EPSS is currently low, treat internet-scale exploitation as unlikely, but do not defer remediation on multi-user or shared GPU hosts where local attackers are realistic.
• Track distribution advisories for exact fixed package versions because fixed versions were not provided in the input data.