https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 04 Nov 2026 21:06:14 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99147 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/exec: don&#39;t immediately add prelocked obj to array of locked objs</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again.</p> <p>If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/exec: don&#39;t immediately add prelocked obj to array of locked objs</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again.</p> <p>If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop.</p> https://db.gcve.eu/vuln/fkie_cve-2026-99147 https://db.gcve.eu/vuln/ghsa-f9vc-r5f2-m3x9 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/exec: don&#39;t immediately add prelocked obj to array of locked objs</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again.</p> <p>If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/exec: don&#39;t immediately add prelocked obj to array of locked objs</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again.</p> <p>If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop.</p> https://db.gcve.eu/vuln/ghsa-f9vc-r5f2-m3x9 https://db.gcve.eu/vuln/msrc_cve-2026-99147 msrc_CVE-2026-99147 https://db.gcve.eu/vuln/msrc_cve-2026-99147 https://db.gcve.eu/vuln/ubuntu-cve-2026-99147 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 164 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/exec: don&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 164 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/exec: don&#39;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.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-99147