https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 24 Oct 2026 21:37:15 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-98999 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin</p> <p>xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo&#39;s pinned_link list membership in xe-&gt;pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo&#39;s pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link.</p> <p>If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count &gt; 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -&gt; 0), it never touches pinned_link, leaving the bo linked on xe-&gt;pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced.</p> <p>The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue.</p> <p>Move the pinned_link removal into xe_bo_account_unpin(), which…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin</p> <p>xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo&#39;s pinned_link list membership in xe-&gt;pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo&#39;s pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link.</p> <p>If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count &gt; 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -&gt; 0), it never touches pinned_link, leaving the bo linked on xe-&gt;pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced.</p> <p>The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue.</p> <p>Move the pinned_link removal into xe_bo_account_unpin(), which…</p> https://db.gcve.eu/vuln/fkie_cve-2026-98999 https://db.gcve.eu/vuln/ghsa-7j8x-2fgw-fvx8 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin</p> <p>xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo&#39;s pinned_link list membership in xe-&gt;pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo&#39;s pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link.</p> <p>If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count &gt; 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -&gt; 0), it never touches pinned_link, leaving the bo linked on xe-&gt;pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced.</p> <p>The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue.</p> <p>Move the pinned_link removal into xe_bo_account_unpin(), which…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin</p> <p>xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo&#39;s pinned_link list membership in xe-&gt;pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo&#39;s pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link.</p> <p>If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count &gt; 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -&gt; 0), it never touches pinned_link, leaving the bo linked on xe-&gt;pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced.</p> <p>The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue.</p> <p>Move the pinned_link removal into xe_bo_account_unpin(), which…</p> https://db.gcve.eu/vuln/ghsa-7j8x-2fgw-fvx8