CVE-2026-52980

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: sched/fair: Fork edilen varlıklar başlatılırken rel_deadline temizleniyor Yeni fork edilmiş bir sched_entity, se->rel_deadline beklenmedik şekilde ayarlanmış olarak fair sınıfına girdiğinde, yield tarafından tetiklenen bir çökme meydana gelebilir. Hata veren sekans şöyledir: 1. se->rel_deadline hala ayarlanmış durumdayken bir görev fork edilir. 2. __sched_fork(); vruntime, vlag ve diğer sched_entity durumlarını başlatır ancak rel_deadline değerini temizlemez. 3. İlk kuyruğa ekleme işleminde, enqueue_entity() fonksiyonu place_entity() fonksiyonunu çağırır. 4. se->rel_deadline ayarlı olduğu için place_entity(), se->deadline değerini göreceli bir son tarih (relative deadline) olarak değerlendirir ve mevcut vruntime değerini ekleyerek bunu mutlak bir son tarihe dönüştürür. 5. Ancak, fork edilen varlığın son tarihi bu yeni zamanlama örneği için geçerli bir miras alınmış göreceli son tarih değildir; bu nedenle dönüşüm anormal derecede büyük bir son tarih üretir. 6. Görev daha sonra sched_yield() fonksiyonunu çağırırsa, yield_task_fair() fonksiyonu se->vruntime değerini se->deadline değerine ilerletir. 7. Şişirilmiş vruntime değeri daha sonra şu kuyruğa ekleme yolunda kullanılır ve burada vruntime türevli anahtar, varlık ağırlığı ile çarpıldığında taşmaya neden olabilir. 8. Bu durum cfs_rq->sum_w_vruntime değerini bozar, EEVDF uygunluk hesaplamasını etkisiz hale getirir ve sonunda tüm varlıkların uygunsuz görünmesine neden olabilir. pick_next_entity() ardından beklenmedik şekilde NULL döndürebilir ve bu da daha sonra bir NULL dereference hatasına yol açar. Yakalanan bir izleme (trace), etkiyi açıkça göstermektedir. Yield öncesinde varlığın vruntime değeri yaklaşık olarak şuydu: 9834017729983308 yield_task_fair() çalıştıktan sonra: se->vruntime = se->deadline vruntime şu değere sıçradı: 19668035460670230 ve son tarih daha sonra şu değere ilerledi: 19668035463470230 Bu durum, yield_task_fair() değerini vruntime'a kopyalamadan önce son tarihin zaten anormal derecede büyüdüğünü göstermektedir. rel_deadline yalnızca se->deadline gerçekten vruntime'a karşı konumlandırılması gereken göreceli bir son tarih taşıdığında anlamlıdır. Yeni fork edilmiş bir sched_entity bu durumu miras almamalı veya korumamalıdır. İlk kuyruğa eklemenin yeni varlığın son tarihini bayat bir göreceli son tarih olarak yorumlamaması için, diğer sched_entity çalışma zamanı durumlarıyla birlikte __sched_fork() içerisinde se->rel_deadline temizlenmiştir.