CVE-2026-68104

What it actually does

This is a Linux kernel use-after-free flaw in the AMDGPU DRM driver’s power-management domain cleanup path. The driver frees the ACP generic power-domain structure without first unregistering it from the kernel’s global generic power-domain list, leaving a stale pointer that can later be referenced by kernel power-management code. Depending on reachability and system configuration, this can result in kernel memory corruption, GPU driver instability, a kernel panic, or potentially privilege escalation from local code execution to kernel-level execution. Exploit maturity is currently reported as none, and there is no known CISA KEV listing or ransomware association.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware may experience unexpected crashes, degraded graphics/GPU availability, or broader host instability. If the vulnerable code path is exploitable by a local user or workload, the risk could extend to full system compromise because kernel memory corruption bugs can bypass normal user-space isolation. The vulnerability was published recently, so organizations should prioritize inventory and patch planning even though there is no public exploitation signal at this time.

How an attack unfolds

An attacker would first need access to a system running a vulnerable Linux kernel with the AMDGPU driver and relevant AMDGPU power-management functionality in use. The attacker would attempt to trigger the driver cleanup path that frees the ACP generic power-domain object while it remains registered in the kernel’s global power-domain structures. After the object is freed, the attacker would try to cause later power-management activity to reference the stale pointer. In a simple failure case, this produces a kernel oops or panic. In a more advanced exploitation scenario, the attacker would attempt heap grooming so the freed memory is reallocated with attacker-influenced data before the stale pointer is dereferenced, potentially turning the use-after-free into kernel memory corruption or privilege escalation. No mature public exploit is currently known from the provided intelligence.

How to fix it

Upgrade to a Linux kernel release that includes the AMDGPU fix which calls pm_genpd_remove() before freeing the ACP generic power-domain object and clears the pointer after free. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel stable branch once available. As interim risk reduction, restrict local shell access to trusted users, limit untrusted GPU workloads, disable or blacklist the amdgpu driver only where operationally acceptable, and consider using non-affected kernels or hardware configurations for high-risk multi-user systems until patched.

How to confirm the fix worked

Confirm the running kernel contains the AMDGPU patch that unregisters the generic power domain before freeing it. Validate by checking vendor advisories and installed package changelogs for the backported fix, or by verifying the source includes a pm_genpd_remove() call before freeing the ACP generic power-domain structure in the AMDGPU driver cleanup path. After patching, reboot into the fixed kernel and confirm the active kernel version matches the updated package. For exposure validation, identify systems with AMDGPU hardware and the amdgpu kernel module loaded using tools such as lsmod, lspci, modinfo, package inventory, and kernel version reporting.

Typical attack path

1. Identify a Linux host running a vulnerable kernel with the AMDGPU DRM driver active.
2. Obtain local code execution or another way to trigger GPU or power-management state transitions.
3. Force the AMDGPU ACP generic power-domain teardown path where the object is freed without being removed from the global power-domain list.
4. Trigger subsequent generic power-domain activity that dereferences the stale pointer.
5. Cause a kernel crash or attempt controlled memory reuse to escalate privileges or execute code in kernel context.

How to detect it

Look for evidence of prior triggering in kernel and system logs rather than network telemetry, because this is a local kernel-driver memory-safety issue. Useful sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, pstore/ramoops records, kdump/vmcore artifacts, crash utility output, audit logs for local user activity before crashes, and endpoint telemetry showing GPU-related commands or workloads. Search for kernel oops, panic, BUG, general protection fault, KASAN use-after-free, slab corruption, NULL or invalid pointer dereference, and call traces involving amdgpu, ACP, generic power domains, or pm_genpd functions. Correlate any GPU driver crash or host reboot with local logins, container workloads, graphical sessions, compute jobs, or repeated GPU reset events. Absence of these artifacts does not prove non-exploitation, especially if crash logging or persistent kernel logging is not enabled.

• amdgpu
• drm/amdgpu
• pm_genpd_remove
• genpd
• generic power domain
• acp_genpd
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• Call Trace:
• GPU reset
• amdgpu: GPU reset
• amdgpu: ring
• amdgpu: failed
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/module/amdgpu
• /proc/modules
• /sys/kernel/debug/dri

What your security team should do

• Inventory Linux systems using AMDGPU hardware or loading the amdgpu kernel module.
• Track Linux distribution and vendor advisories for fixed kernel packages, then patch and reboot affected systems promptly.
• Prioritize multi-user systems, developer workstations, GPU-enabled compute nodes, VDI hosts, and any environment where untrusted users or workloads can access GPU functionality.
• Temporarily restrict local access and untrusted GPU workloads on affected systems until fixed kernels are deployed.
• Monitor kernel logs for AMDGPU, ACP, generic power-domain, use-after-free, slab, oops, panic, or BUG messages that may indicate attempted triggering or instability.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, package versions, loaded module lists, and recent user activity for forensic review.