CVE-2026-98780: drm/amdgpu: fix IP instance memory leak on kobject add failure
drm/amdgpu: fix IP instance memory leak on kobject add failure
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1 - Compensating control
In amdgpu_discovery_sysfs_ips(), call kobject_put() when kobject_add() fails to drop the initial reference and allow ip_hw_instance_release() to free the allocation, while continuing with the remaining IP entries.
Event History
Frequently Asked Questions
What condition triggers the leak?
The leak occurs only when amdgpu_discovery_sysfs_ips() cannot register an IP-instance kobject because kobject_add() fails. On that error path, the allocated ip_hw_instance was not released.
What is the practical impact on affected systems?
Each failed kobject registration can leave an ip_hw_instance allocation unreleased. The normal sysfs teardown path cannot clean up these objects because failed kobjects are not retained in the kset list.
Does a failed IP-instance sysfs registration stop processing of other entries?
No. The intended behavior remains best-effort: processing continues with the remaining IP entries after a registration failure. The fix adds reference cleanup for the failed entry.