VulnerabilityPublished 28 Oct 2026

CVE-2026-99148: Linux kernel · drm/amdgpu: keep the eviction fence until the last handle is closed

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in dce8f7f03a47b1744dccf506268f9229b67fab47 : update Linux kernel when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in dce8f7f03a47b1744dccf506268f9229b67fab47, 6467c4cc83b94850bfea614e9f98276edf9a7c3f, 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to dce8f7f03a47b1744dccf506268f9229b67fab47, 6467c4cc83b94850bfea614e9f98276edf9a7c3f or 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 31f7efcdca4d1caaa3a0babc33377e27e6f9b593, < dce8f7f03a47b1744dccf506268f9229b67fab47	Fixed in dce8f7f03a47b1744dccf506268f9229b67fab47
LinuxLinux	Affected ≥ 31f7efcdca4d1caaa3a0babc33377e27e6f9b593, < 6467c4cc83b94850bfea614e9f98276edf9a7c3f	Fixed in 6467c4cc83b94850bfea614e9f98276edf9a7c3f
LinuxLinux	Affected ≥ 31f7efcdca4d1caaa3a0babc33377e27e6f9b593, < 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b	Fixed in 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b
LinuxLinux	Affected =6.16	Fixed in–

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

Community reviews

Loading reviews…