Zafiyet.live Keşfet. Değerlendir. Düzelt. Doğrula.
  • Son 7 gün

CVE-2026-98999

Linux çekirdeğinde xe sürücüsünde eski pinned_link girdisi nedeniyle bellek kullanım sonrası hatası

Linux

Yüksek 7,8 CVSS 3.1
Yayımlandı
Güncellendi
24 Eki 2026
Açık yaşı
5 gün
Kaydı açan
Linux

ÖzetTürkçe

Linux çekirdeğinin drm/xe sürücüsünde, bir bellek nesnesi (bo) hem harici olarak (örneğin dma-buf dışa aktarımı) hem de çerçeve tamponu (fb) olarak sabitlendiğinde, harici sabitleme kaldırıldıktan sonra fb tarafındaki son sabitleme kaldırma işlemi pinned_link listesinden girdiyi silmez. Bu durumda nesne xe->pinned.late.external listesinde süresiz olarak bağlı kalır. Nesne daha sonra serbest bırakıldığında, bu eski liste girdisi serbest bırakılmış belleğe işaret eder; bu da liste bozulmasına ve listenin bir sonraki gezilmesinde ya da birleştirilmesinde bellek kullanım sonrası hatasına yol açabilir. Düzeltmeyle pinned_link kaldırma işlemi, her sabitleme kaldırma yolunda (çekirdek, harici, çerçeve tamponu ve yedek nesne) pin_count 1 -> 0 geçişinden hemen önce çalışan xe_bo_account_unpin fonksiyonuna taşınmıştır. Yedek nesne sabitleme noktaları aynı bypass özelliğine sahip olsa da bir sabit listeye eklenmedikleri için bu liste bozulma sorunundan etkilenmez.

Kaynaktaki açıklama (İngilizce)

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin

xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's
pinned_link list membership in xe->pinned.late.external, based on
whether the current call is the outermost pin or the final unpin.
However, the same external bo'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.

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 > 1 and leaves the bo on pinned_link. When the fb
unpin later performs the true last unpin (pin_count 1 -> 0), it never
touches pinned_link, leaving the bo linked on xe->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.

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.

Move the pinned_link removal into xe_bo_account_unpin(), which already
runs on every unpin path (kernel, external, framebuffer, backup
object) right before the true 1 -> 0 pin_count transition. Since
list_del_init() only operates on the node itself, this removal is
list-agnostic and safe to perform regardless of which list (external
or kernel_bo_present) the bo happens to be linked on, or which code
path is performing the final unpin. Drop the now-redundant explicit
list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin().

v2:
- New patch

v3:
- Rebased on changes to previous patch.

(cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01)

Bu açığın açıklamasını Türkçeye çevirdik. Adım adım çözüm önerilerini kritik ve yeni açıklar için hazırlıyoruz; düzeltilmiş sürüm aşağıdaki tabloda, ayrıntılar üreticinin duyurusunda.

Etkilenen sürümler1 yazılım

YazılımEtkilenenDüzeltildiği sürüm
Linux 6.8 –
< 6.8 Etkilenmiyor –
≥ 6.18.57 Etkilenmiyor –
≥ 7.2.11 Etkilenmiyor –

Kaynaklar5 kaynak

Kayıt geçmişi

  1. Yayımlandı

İlgili açıklar

Türkçe metin, resmi kayıtlardaki bilgilerle yapay zekâ yardımıyla yazıldı ve yayından önce otomatik kontrollerden geçti. Bir değişikliği uygulamadan önce üreticinin duyurusuna mutlaka bakın.