Cloudanix VulnDB

CVE-2026-99147

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's graphics handling could let memory become corrupted under certain locking conditions, potentially crashing computers or causing data loss.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The drm_exec locking logic can hold the final reference to a contended object that is about to be destroyed, omitting it from the locked-objects array and later causing a warning or BUG_ON when a driver attempts to attach a dma_fence via drm_exec_for_each_locked_object, resulting in use-after-free style memory corruption.

Why it matters to the business

Linux systems running graphics or display drivers may experience kernel crashes, unexpected reboots, or data corruption during normal operation or under load, leading to downtime and potential loss of work on affected machines.

How an attack unfolds

An attacker triggers DRM object contention to force the pre-lock path, arranges for the contended object to be the last reference holder, then causes a subsequent fence attachment loop that dereferences the now-destroyed object, producing memory corruption.

How to fix it

Update the Linux kernel to a version containing the fix that keeps the pre-locked object out of the locked array until it is explicitly re-mentioned by the driver; rebuild and reboot systems after applying the patch.

How to confirm the fix worked

Confirm the patched drm_exec.c source no longer adds the pre-locked object to the array before explicit driver mention, run DRM locking stress tests, and verify absence of the previous BUG_ON or warning under contention.

Typical attack path

  1. Trigger contention on a DRM object so drm_exec pre-locks it
  2. Ensure the pre-locked object holds the final reference and is destroyed
  3. Invoke driver code that walks locked objects with drm_exec_for_each_locked_object to attach a fence
  4. Trigger the BUG_ON or warning path leading to memory corruption

How to detect it

Inspect kernel logs for drm_exec related BUG_ON or warning messages mentioning locked objects or dma_fence; examine crash dumps for use-after-free patterns in DRM object handling.

What your security team should do

  • Prioritize kernel updates on all systems using DRM graphics drivers
  • Monitor vendor advisories for backported fixes in distribution kernels
  • Test updated kernels in staging environments before broad deployment
  • Review graphics driver code that uses drm_exec locking primitives

The record

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.

Affected packages

Ecosystem Package Introduced Fixed