CVE-2026-43439

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: cgroup: görev taşıma ve yineleme arasındaki yarış durumu düzeltildi Bir görev bir css_set dışına taşındığında, cgroup_migrate_add_task() önce görevi şu şekilde cset->tasks listesinden cset->mg_tasks listesine taşır: list_move_tail(&task->cg_list, &cset->mg_tasks); Eğer bir css_task_iter o anda it->task_pos ile bu görevi işaret ediyorsa, css_set_move_task() yineleyiciyi geçerli tutmak için css_task_iter_skip() fonksiyonunu çağırır. Ancak, görev zaten ->mg_tasks listesine taşındığı için, yineleyici orijinal tasks listesi yerine mg_tasks listesine göre ilerletilir. Sonuç olarak, cset->tasks üzerindeki kalan görevlerin yanı sıra cset->mg_tasks üzerinde kuyruğa alınmış görevler de yineleme sırasında atlanabilir. Bu durum, task->cg_list'in cset->tasks listesinden bağlantısı kesilmeden önce css_set_skip_task_iters() çağrılarak düzeltilmiştir. Bu işlem, tüm aktif yineleyicileri cset->tasks üzerindeki bir sonraki göreve ilerletir; böylece bir görev eşzamanlı olarak taşınırken bile yineleme doğru şekilde devam eder. Bu yarış durumuna gerçek uygulamada araçlandırma olmadan rastlamak zordur ancak cgroup_procs_show() yapay olarak yavaşlatılarak yeniden üretilebilir. Örneğin, bir Android cihazda cgroup_procs_show() içine gecikme eklemek için geçici bir /sys/kernel/cgroup/cgroup_test düğmesi eklenebilir ve ardından şunlar yapılabilir: 1) Üç adet uzun süreli görev başlatılır (PID'ler 101, 102, 103). 2) Bir test cgroup oluşturulur ve görevler bunun içine taşınır. 3) /sys/kernel/cgroup/cgroup_test aracılığıyla büyük bir gecikme etkinleştirilir. 4) Bir kabukta, test cgroup'undan cgroup.procs okunur. 5) Gecikme penceresi içinde, başka bir kabukta PID 102 farklı bir cgroup.procs dosyasına yazılarak taşınır. Bu kurulum altında, cgroup.procs aralıklı olarak PID 103'ü atlarken sadece PID 101'i gösterebilir. Taşıma tamamlandığında, dosya tekrar okunduğunda tüm görevler beklendiği gibi görünür. Bu değişikliğin, css_set_move_task() içindeki mevcut css_set_skip_task_iters() çağrısının kaldırılmasına izin vermediğine dikkat edilmelidir. cgroup_migrate_add_task() içindeki yeni çağrı, yalnızca görev hala cset->tasks üzerindeyken taşıma işlemiyle yarışan yineleyicileri yönetir. Yineleyiciler, görev cset->mg_tasks listesine taşındıktan sonra da başlayabilir. Eğer css_set_skip_task_iters() fonksiyonu css_set_move_task()'dan kaldırılırsa, bu tür yineleyiciler task_pos'un taşınan bir görevi işaret etmeye devam etmesine neden olabilir; bu da hedef css_set üzerinde css_task_iter_advance() fonksiyonunun hatalı çalışmasına, çökmelere veya sonsuz döngülere yol açabilir. Taşıma ve yineleme arasındaki yarış penceresi çok küçüktür ve css_task_iter kritik bir yolda değildir. En kötü durumda, bir yineleyici taşınan işlemin ilk iş parçacığına konumlandırıldığında, cgroup_migrate_add_task() css_set_skip_task_iters() aracılığıyla birden fazla görevi atlamak zorunda kalabilir. Ancak bu durum yalnızca taşıma ve yineleme gerçekten yarıştığında gerçekleştiğinden, performans etkisi burada sağlanan doğruluk düzeltmesine kıyasla ihmal edilebilir düzeydedir.