VulnerabilityPublished 28 Oct 2026

CVE-2026-99147: Linux kernel · drm/exec: don't immediately add prelocked obj to array of locked objs

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in 26401a4999f1596a515b2e704e7066ac09306488 : 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 26401a4999f1596a515b2e704e7066ac09306488, 96d9996e5dbcfabed052c0d9377a382c95fed607, 7a10cd79c4d9a90334fece32fef3a8e5b1a9727b

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 26401a4999f1596a515b2e704e7066ac09306488, 96d9996e5dbcfabed052c0d9377a382c95fed607 or 7a10cd79c4d9a90334fece32fef3a8e5b1a9727b.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 09593216bff15866f95c8ad406cb7fdcec1ee40a, < 26401a4999f1596a515b2e704e7066ac09306488	Fixed in 26401a4999f1596a515b2e704e7066ac09306488
LinuxLinux	Affected ≥ 09593216bff15866f95c8ad406cb7fdcec1ee40a, < 96d9996e5dbcfabed052c0d9377a382c95fed607	Fixed in 96d9996e5dbcfabed052c0d9377a382c95fed607
LinuxLinux	Affected ≥ 09593216bff15866f95c8ad406cb7fdcec1ee40a, < 7a10cd79c4d9a90334fece32fef3a8e5b1a9727b	Fixed in 7a10cd79c4d9a90334fece32fef3a8e5b1a9727b
LinuxLinux	Affected =6.6	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: drm/exec: don't immediately add prelocked obj to array of locked objs When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop.

References

Community reviews

Loading reviews…