CVE-2026-98779

What it actually does

The vulnerability leaves ACP child platform devices registered via mfd_add_devices() without unregistering them or removing them from the power domain when subsequent attachment, reset, or clock enable operations fail, causing a persistent device registration leak in the amdgpu ACP MFD subsystem.

Why it matters to the business

Systems using affected AMD GPUs may experience gradual resource exhaustion or repeated initialization failures during driver load/unload cycles, increasing operational overhead for hardware maintenance and potentially affecting graphics or multimedia workloads on Linux kernels; low exploitability and absence from known campaigns limit urgency.

How an attack unfolds

An attacker with local access capable of repeatedly triggering ACP hardware initialization failures (such as through power domain or clock timing manipulation) could accumulate leaked MFD devices, leading to resource pressure; no remote or unauthenticated exploitation path exists and no threat actors have been observed using it.

How to fix it

Apply the upstream fix that unregisters MFD devices and removes them from the power domain on post-registration failures; update to a Linux kernel containing commit 63da68d6a2279ec945581c990c5a59a5ae8b5560 or later equivalent backport.

How to confirm the fix worked

Confirm the presence of the corrected error-handling paths in acp_hw_init() that explicitly call mfd_remove_devices and power-domain removal on failure after mfd_add_devices; test repeated init-failure scenarios to verify no leaked platform devices remain.

Typical attack path

1. Obtain local access to a system with vulnerable AMDGPU driver
2. Trigger repeated ACP init failure conditions after mfd_add_devices succeeds
3. Accumulate unregistered child devices to exhaust kernel resources

How to detect it

Inspect kernel logs and dmesg for repeated ACP MFD registration messages without corresponding removal on failure paths; examine platform device lists via sysfs or debugfs for orphaned ACP child devices after driver initialization errors.

What your security team should do

• Prioritize kernel updates for AMDGPU systems within standard patch cycles given low EPSS and no KEV listing
• Monitor kernel logs for ACP-related init timeouts or power-domain failures as indirect indicators of exposure
• Review downstream dependent packages that ship custom AMDGPU drivers for equivalent fixes