Cloudanix VulnDB

CVE-2026-99148

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A graphics driver bug can let one program cause memory used by another part of the same program to be taken away too soon, potentially crashing graphics applications or causing errors.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The amdgpu driver detaches a user-queue eviction fence from a buffer object in amdgpu_gem_object_close before verifying that the last bo_va reference has been released, allowing the BO to be evicted while mappings belonging to still-open handles remain active.

Why it matters to the business

Workloads using AMD GPUs with user queues may experience unexpected GPU memory eviction, leading to application crashes, data corruption, or denial of service on systems running the affected kernel versions.

How an attack unfolds

An attacker with local access opens a GEM buffer object multiple times within the same file descriptor (via GEM_FLINK/GEM_OPEN), closes one handle to trigger premature fence detachment, then continues accessing the buffer through the remaining mapping; the driver may evict the BO without suspending the queue, causing faults or incorrect results.

How to fix it

Update to a Linux kernel containing the fix from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a (or its backports) so that the eviction fence is detached only when the final bo_va reference is released.

How to confirm the fix worked

Confirm the kernel source contains the corrected logic in amdgpu_gem_object_close that checks bo_va->ref_count before detaching the fence; test by opening a BO twice, closing one handle, and verifying the fence remains attached until the final close.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with an AMD GPU
  2. Create multiple handles to the same GEM BO from the same process
  3. Trigger amdgpu_gem_object_close on one handle while other handles and mappings remain active
  4. Continue GPU operations that rely on the now-evictable BO
  5. Observe eviction without queue suspension resulting in faults or corruption

How to detect it

Review kernel logs for amdgpu fence attach/detach sequences around GEM_CLOSE operations; look for patterns where a detach occurs while additional handles to the same BO remain open.

What your security team should do

  • Prioritize kernel updates on systems with AMD GPUs that expose user queues or perform heavy GEM operations
  • Monitor upstream stable and distribution kernel releases for the backported commit
  • Restrict unprivileged access to GPU device nodes until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: keep the eviction fence until the last handle is closed amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a)

Affected packages

Ecosystem Package Introduced Fixed