Cloudanix VulnDB

CVE-2026-98780

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Gain local execution context on a Linux system with amdgpu loaded
  2. Trigger conditions that cause kobject_add to return failure inside amdgpu_discovery_sysfs_ips
  3. Repeat the failure path to accumulate unreleased ip_hw_instance allocations
  4. 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