CVE-2024-58057

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: idpf: workqueue'ların unbound olarak dönüştürülmesi Bir workqueue `WQ_UNBOUND` ile oluşturulduğunda, iş öğeleri, ana çalışanları herhangi bir belirli CPU'ya bağlı olmayan özel çalışan havuzları tarafından karşılanır. Varsayılan yapılandırmada (yani `queue_delayed_work` ve benzerleri iş öğesinin hangi CPU üzerinde çalışacağını belirtmediğinde), `WQ_UNBOUND` iş öğesinin, kuyruğa alındığı CPU ile aynı düğümdeki herhangi bir CPU üzerinde yürütülmesine izin verir. Bu çözüm potansiyel olarak yerelliği feda etse de, iş öğesinin zamanlandığı işlemcinin CPU süresine hakim olabilecek diğer süreçlerle yaşanacak çekişmeyi önler. Bu sadece teorik bir sorun değildir: belirli bir senaryoda, yanlış yapılandırılmış bir süreç CPU0'ın zamanının çoğunu tüketerek kworker'a CPU zamanının %0,5'inden daha azını bırakmıştır. Sonuç olarak, CPU0 üzerindeki kworker'ı kullanan IDPF workqueue'ları büyük tamamlanma gecikmeleri yaşamış; bu da performans düşüşüne, zaman aşımı hatalarına ve nihayetinde sistem çökmesine neden olmuştur. * Performans artışını ölçmek için manuel bir test de gerçekleştirdim. Test, CPU 0'ın mümkün olduğunca fazlasını tüketen rakip bir süreçten (`./stress --cpu 2`) oluşmaktadır. Bu süreç, CPU0'a bağlamak için `taskset 01` altında çalıştırılır ve başlatıldıktan sonra önceliği `chrt -pQ 9900 10000 ${pid}` ve `renice -n -20 ${pid}` ile değiştirilir. Ardından, `queue_delayed_work`, `mod_delayed_work` vb. tüm çağrılar CPU 0'ı kullanacak şekilde düzenlenerek IDPF sürücüsünün CPU0'ı tercih etmesi sağlanır. Son olarak, workqueue olayları için `ktraces` verileri toplanır. Mevcut yama olmadan, rakip süreç `workqueue_queue_work` ve `workqueue_execute_start` arasında, testlerimde `30ms` kadar yüksek olan rastgele gecikmelere neden olabilmektedir. Mevcut yama uygulandığında ise workqueue, aynı düğümdeki başka bir boş CPU'ya taşınabilir ve diğer her şey eşit tutulduğunda görebildiğim maksimum gecikme `6us` olmuştur.