GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Check your stack
CVE-2026-99148unknown

drm/amdgpu: keep the eviction fence until the last handle is closed

Impact

In the Linux kernel, the following vulnerability has been resolved:

Source excerpt · Linux

Affected packages

This source has no supported package-version data for matching. You can read the advisory here, but this record alone cannot power a dependency check.

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

Linux · Linux

Other versions: unaffected

Version / rangeSource status
31f7efcdca4d1caaa3a0babc33377e27e6f9b593 to before dce8f7f03a47b1744dccf506268f9229b67fab47affected
31f7efcdca4d1caaa3a0babc33377e27e6f9b593 to before 6467c4cc83b94850bfea614e9f98276edf9a7c3faffected
31f7efcdca4d1caaa3a0babc33377e27e6f9b593 to before 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2baffected
Linux version evidence

Linux · Linux

Other versions: affected

Version / rangeSource status
6.16affected
0 to before 6.16unaffected
6.18.59 through 6.18.* (inclusive)unaffected
7.2.13 through 7.2.* (inclusive)unaffected
7.3 through * (inclusive)unaffected
Linux version evidence

Original source description

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)

References