CVE-2026-74591

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: mm/filemap: __filemap_add_folio() yeniden denemeden önce index'i geri yükler __filemap_add_folio()'nun çakışma bölme döngüsünde xas_set_order() tekrar tekrar uygulanır: her uygulama xas.xa_index'i değiştirir ve o aşamada denenmeye çalışılan split_order'a göre aşağı yuvarlar: ve her şey amaçlandığı gibi giderse, sonunda (veya hemen) gerekli folio_order'a bir xas_try_split() üzerinde yakınsar ve xas.xa_index artık index ile aynı olur: ardından xas_store() yeni folio'yu oradaki xarray'e yerleştirir. Ancak yeni bir düğüm gerekliyse ve GFP_NOWAIT ayırması bir tane alamadıysa, kilit bırakılır, ayırma için xas_nomem() kullanılır ve dizi yeniden denenir. Kilit yeniden alındığında xarray'in (o kısmı) değişmemişse sorun yoktur. Peki ya çakışma bu arada başka bir iş parçacığı tarafından çözüldüyse (belki de aynı şeyi yaparak, aynı index'e bir folio ekleyerek)? O zaman folio'muzu xarray'e ara bir aşağı yuvarlanmış index'te koyma tehlikesi yok mudur? CONFIG_DEBUG_VM=y bunu denetlerken !folio_contains() hatası bunu izler. Bunu düzeltmek için döngünün sonunda özgün xas.xa_index'i geri yüklemek üzere bir xas_set_order() uygulanır, böylece yeniden deneme kilidi yeniden aldıktan sonra tam bir yeniden değerlendirme yapar ve xas_store()'a yanlış index ile ulaşamaz. Üretimde nadir SIGILL ve SIGSEGV'ler görülüyordu, çalıştırılabilir metin ait olduğu yerden bir sayfa uzakta bulunuyordu, hata ayıklama etkinleştirildiğinde !folio_contains() hatası tetikleniyordu: bu yama uygulandığından beri belirtiler görülmedi.