CVE-2026-98087

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: sched/rt,dl: Bir push adayı seçerken migrate-disabled görevleri atla migrate_disable() uygulanmış bir RT görevi başka bir CPU'ya taşınamaz, ancak zamanlayıcı böyle bir görevi hala o CPU'nun pushable listesinde (rq->rt.pushable_tasks) tutmaya devam eder ve çalışma kuyruğunu hala RT-aşırı yüklü (rq->rt.overloaded = 1) olarak işaretler. Bu nedenle RT dengeleyici, bu CPU'yu taşınacak bir göreve sahipmiş gibi görmeye devam eder ve görevi taşımaya çalışır, ancak push işlemi asla başarılı olamaz. Baş (head) sabitlendiğinde, push_rt_task() da vazgeçmez. Bunun yerine, a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing") commit'i ile eklenen per-CPU stopper'ı kullanarak rq->curr'u push etmeye geri döner. CPU, bu yeniden deneme döngüsünde onlarca milisaniye harcar. Çekirdek gerçek zamanlı işler için izole edilmiştir, ancak döngü sırasında süresinin neredeyse yarısı başarılı olamayan push işlemleri tarafından tüketilir. sched_switch etkinleştirilmiş ve 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") commit'i uygulanmış etkilenen CPU'nun bir ftrace yakalaması, CPU süresinin nereye gittiğini göstermektedir. Eşit önceliğe sahip iki SCHED_FIFO görevi CPU'yu paylaşmıştır; taskA migrate_disable() uygulanmış ve kuyruğa alınmış, taskB ise rq->curr durumundadır. 89 ms'lik bir pencerede, taskB sadece 52 ms CPU alabilmiştir. Diğer 37 ms stopper thread'ine gitmiştir. Zamanlayıcı, pushable listesinin sabitlenmiş başı olan taskA'yı push etmeyi denemeye devam etmiş, bunun yerine taskB'yi push etmeye geri dönmüş ve stopper'ı 5204 kez uyandırmıştır. Bu push işlemlerinin her biri başarısız olmuş ve hiçbir görev taşınmamıştır. taskA tüm süre boyunca çalıştırılabilir kalmış, kuyrukta beklemiş ve hiç çalışmamıştır. taskB'nin push edilmesi, yeniden kontrol sırasında başarısız olur. find_lock_lowest_rq(), hedef rq kilidini almak için rq kilidini bırakır, ardından "task != pick_next_pushable_task(rq)" ile tekrar kontrol eder. Push edilen görev taskB'dir, ancak pick fonksiyonu pushable listesinin başı olan taskA'yı döndürür. taskB, rq->curr'dur ve set_next_task_rt() çalışan görevi bu listeden kaldırır, dolayısıyla taskB asla listenin başında olamaz. Kontrol, pushable listesinden alınan bir aday bekler, ancak fallback mekanizması bu listede asla bulunmayan rq->curr'u push eder. Bu nedenle kontrol her seferinde başarısız olur. .--> push-IPI gelir | | | v | pushable head = taskA -> sabitlenmiş, push edilemez | | | v | bu yüzden taskB push edilir -> migration/N uyarılır, bir stop-class | | thread olduğu için taskB'yi öne geçer (preempts) | v | yeniden kontrol taskB'yi pushable head ile karşılaştırır, | ki bu hala taskA'dır -> vazgeçilir | | | v | hiçbir şey taşınmadı, taskA hala kuyrukta, rq hala aşırı yüklü | | '----------' her ~17 us'de bir tekrarlanır, 89 ms boyunca 5204 kez Döngü kendi kendini durduramaz. Her tur, çalışma kuyruğunu tam olarak olduğu gibi bırakır, bu nedenle bir sonraki push-IPI aynı şeyi yapar. Yakalamada, işlem ancak taskB kendi kendine uykuya daldığında sona ermiştir. taskA daha sonra yerel olarak seçilmiş ve pushable listesinden çıkmıştır. Penceredeki görev başına CPU süresi, sched_switch verilerine göre: taskB 51.95 ms gerçek iş migration/N 37.18 ms hiçbir şey taşınmadı taskA 0.00 ms tüm süre boyunca kuyruktaydı, hiç seçilmedi idle 0.01 ms Aynı pencere üzerindeki sayımlar: 7667 bu CPU'da işlenen push-IPI'lar 17481 pick_next_pushable_task() taskA'yı döndürdü, hala sabitlenmiş 5204 find_lock_lowest_rq() yeniden kontrolde vazgeçti 1 gerçekten tamamlanan push işlemi 0 taskA migrasyonları CPU süreleri ve pencere uzunluğu standart sched_switch tracepoint'inden gelmektedir. Sayımlar için bu inceleme kapsamında RT dengeleyici içine tracepoint'ler eklenmiştir. Self-IPI yolu yukarıdaki rto_next_cpu() düzeltmesiyle kapatılmıştır ve bu kısım çalışmaktadır. Ancak sabitlenmiş görev hala push edilebilir olarak bildirildiği için çalışma kuyruğu hala aşırı yüklü olarak işaretlenmektedir. Diğer CPU'lar artık kendi RT dengelemeleri sırasında push-IPI'lar göndermekte ve aynı döngü tekrar çalışmaktadır. Self-IPI yolunun kapatılması, sabitlemeyi durdurmamıştır.