CVE-2026-45878

What it actually does

This is a local Linux kernel memory-safety flaw in the AMD Kernel Fusion Driver debug address-watch handling code. A userspace caller can provide an out-of-range watch_id value that is treated inconsistently as unsigned and signed, allowing invalid bit shifts and out-of-bounds access to the pdd->watch_points array in the amdkfd debug path. Because the vulnerable code executes in kernel context, successful exploitation can potentially corrupt kernel memory, crash the system, or support local privilege escalation. The CVSS vector indicates local access with low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels with AMD GPU/KFD functionality exposed to local users, containers, workloads, or untrusted compute jobs may be vulnerable to denial of service or privilege escalation. In practical terms, an attacker who already has local code execution could potentially crash GPU-enabled Linux hosts or gain elevated control of the operating system, which is especially relevant for shared workstations, CI/build hosts, GPU compute clusters, VDI, and multi-user research or AI/ML environments. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so internet-scale exploitation is less likely; however, kernel local privilege escalation issues should still be prioritized on shared or high-value systems.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on an affected Linux system. They then interact with the AMD KFD device/debug interface, typically through GPU compute or debug-related ioctls exposed by the kernel driver. Instead of supplying a valid watch identifier in the expected range, the attacker supplies a very large unsigned watch_id value. Vulnerable helper code may interpret or manipulate that value as a signed integer and perform invalid shifts or insufficient bounds checks. When the clear or set address-watch path later indexes the watch_points array using the attacker-controlled value, memory outside the intended array can be accessed or corrupted. Depending on kernel configuration, hardware state, memory layout, and exploit reliability, this may result in a kernel oops/panic, GPU driver instability, or controlled corruption useful for privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream amdkfd fix for debug address watch v2 bounds checking. The fixed code validates watch_id before use, rejects values greater than or equal to MAX_WATCH_ADDRESSES, and uses safe BIT(watch_id) operations. Because exact fixed package versions were not provided, use your Linux distribution's security advisory and kernel changelog to identify the patched kernel for CVE-2026-45878, then reboot into the updated kernel. If immediate patching is not possible, reduce exposure by restricting untrusted local access to GPU compute/debug functionality, limiting access to /dev/kfd and related GPU device nodes, disabling AMD KFD/ROCm workloads where not required, avoiding multi-tenant scheduling on affected GPU hosts, and applying strong workload isolation until patched.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, has been updated to a vendor kernel containing the amdkfd watch_id bounds-checking fix. Validate with uname -a, distribution package tools, and vendor advisories or changelogs referencing the amdkfd debug address-watch fix. Confirm that systems have been rebooted after the kernel update. On hosts where AMD KFD is not required, verify that /dev/kfd is absent or access is restricted to trusted users/groups. Review dmesg or journalctl -k for recent amdkfd, amdgpu, KFD debug, UBSAN, KASAN, general protection fault, or kernel oops messages before and after remediation. If using vulnerability scanning, ensure the scanner checks the active kernel version and distribution backport status rather than only upstream version numbers.

Typical attack path

1. Gain local code execution on a Linux host that runs an affected kernel and exposes AMD KFD/amdgpu functionality.
2. Open or interact with the AMD KFD/GPU debug interface, commonly associated with /dev/kfd and amdgpu compute/debug functionality.
3. Create or reach a debug address-watch state for an AMD GPU process/device context.
4. Submit a maliciously large watch_id value outside the valid MAX_WATCH_ADDRESSES range, especially values larger than INT_MAX.
5. Trigger the vulnerable set or clear address-watch path in amdkfd.
6. Cause invalid bit shifting and/or out-of-bounds access to the watch_points array in kernel memory.
7. Use the resulting memory corruption to crash the host or attempt local privilege escalation.

How to detect it

Retrospective detection should focus on kernel telemetry and local activity because exploitation is local and may leave few application-level traces. Review journalctl -k, dmesg, kern.log, syslog, auditd, EDR, and crash dump data for amdkfd or amdgpu faults involving KFD debug address-watch code, invalid shifts, out-of-bounds array access, kernel oopses, general protection faults, KASAN/UBSAN reports, or panics. Correlate events with local logins, sudo/session starts, container launches, GPU compute jobs, ROCm/HIP workloads, and access to /dev/kfd. In auditd or EDR telemetry, look for unusual low-privileged processes opening /dev/kfd, repeated GPU debug ioctl activity, or crashes occurring immediately after untrusted workloads interact with AMD GPU devices. Kernel memory-corruption exploitation may not produce a deterministic IOC, so absence of logs does not prove absence of exploitation; preserve vmcores, pstore records, and recent kernel logs for forensic review if crashes occurred before patching.

• /dev/kfd
• amdkfd
• amdgpu
• kfd_debug.c
• kfd_dbg_trap_clear_dev_address_watch
• kfd_dbg_owns_dev_watch_id
• watch_points
• clear_address_watch
• debug address watch
• UBSAN: shift-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c
• drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c
• watch_id
• pdd->watch_points

What your security team should do

• Prioritize patching shared, multi-user, GPU compute, AI/ML, research, VDI, CI, and workstation systems where untrusted or semi-trusted users can run local code.
• Inventory Linux systems with AMD GPUs, amdgpu, ROCm, or /dev/kfd exposed, and map them to kernel versions and distribution security advisories.
• Upgrade affected hosts to a vendor-patched kernel and reboot to activate the fix.
• Temporarily restrict access to /dev/kfd and related GPU device nodes to trusted users only until patching is complete.
• Monitor kernel logs for amdkfd/amdgpu crashes, KASAN/UBSAN findings, oopses, and general protection faults that reference kfd_debug.c or address-watch functionality.
• Treat unexplained kernel crashes on affected AMD GPU systems as potentially security-relevant, especially if they correlate with local user activity or GPU debug/compute workloads.
• For containerized GPU workloads, confirm that device passthrough does not expose /dev/kfd to untrusted containers unnecessarily.
• Because there is no current KEV listing and EPSS is low, handle as a high-impact local kernel issue rather than an externally exploitable emergency, unless your environment has untrusted local users.