CVE-2026-98780
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A small programming mistake in the graphics driver can slowly leak memory on computers with certain AMD graphics cards until the system needs a restart.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to call kobject_put after kobject_add failure in amdgpu_discovery_sysfs_ips leaves an allocated ip_hw_instance with its embedded kobject unreleased, bypassing the normal release path in ip_hw_instance_release and causing a permanent memory leak.
Why it matters to the business
Over repeated trigger conditions on AMD GPU systems, gradual memory exhaustion can occur leading to degraded performance or system instability requiring reboots; low immediate urgency given no known exploitation or ransomware use but still relevant for long-running kernel deployments.
How an attack unfolds
An attacker with local access or the ability to influence sysfs registration paths repeatedly forces kobject_add to fail (for example via resource pressure or concurrent operations) so that kzalloc_flex allocations accumulate without being freed; no remote code execution path exists and no named threat actors are associated.
How to fix it
Update to a kernel containing the referenced commit (cherry-picked from 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1) that adds the missing kobject_put call on kobject_add failure while preserving best-effort continuation for remaining IP entries.
How to confirm the fix worked
Inspect the amdgpu_discovery.c source for the presence of kobject_put immediately after a failed kobject_add return check in amdgpu_discovery_sysfs_ips; confirm via kernel version or build logs that the patch is applied.
Typical attack path
- Gain local execution context on a Linux system with amdgpu loaded
- Trigger conditions that cause kobject_add to return failure inside amdgpu_discovery_sysfs_ips
- Repeat the failure path to accumulate unreleased ip_hw_instance allocations
- Observe gradual kernel memory depletion over time
How to detect it
Look in kernel memory statistics and slab allocator usage for sustained growth in amdgpu-related objects without corresponding sysfs entries; correlate with logs showing kobject_add failures during device discovery.
What your security team should do
- Prioritize kernel updates for AMD GPU hosts within standard patch windows
- Monitor memory usage trends on affected systems for unexplained growth
- Review static analysis findings on similar kobject handling patterns in other drivers
The record
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix IP instance memory leak on kobject add failure amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with kzalloc_flex() and initializes its embedded kobject before calling kobject_add(). If kobject_add() fails, the return value is ignored and execution continues without dropping the initial kobject reference. The failed kobject is not retained in the kset list, so the normal sysfs teardown path cannot find it. As a result, ip_hw_instance_release() is never called and the ip_hw_instance allocation is leaked. Call kobject_put() when kobject_add() fails so the initial reference is dropped and ip_hw_instance_release() can free the allocation. Keep the existing best-effort sysfs behavior by continuing with the remaining IP entries after the failed registration. The issue was identified by a static analysis tool I developed and confirmed by manual review. (cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1)
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|