CVE-2026-64560

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: posix-cpu-timers: Lider olmayan exec() yarışından kaynaklanan UAF'yi önle Wongi ve Jungwoo, UAF ile sonuçlanabilen lider olmayan exec() ile ilgili bir yarışı çözümleyip bildirdi: sys_timer_delete() exec() posix_cpu_timer_del() // Eski lideri gözlemler p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // İşlem yapmadan döner if(!sighand) return 0; free_posix_timer(); Silinen zamanlayıcı, exec() sırasında TGID hedefli bir zamanlayıcı devralındığı için p->signal içinde kurulmuş ve kuyruğa alınmış olmadıkça bu "zararsızdır". sys_timer_delete() temel posix zamanlayıcı nesnesini serbest bıraktığından, run_posix_cpu_timers() veya diğer zamanlayıcılar üzerindeki herhangi bir timerqueue ile ilgili ekleme/silme işlemi, serbest bırakılan nesnenin timerqueue düğümüne erişecek ve bu da bir UAF ile sonuçlanacaktır. posix_cpu_timer_set() ile karşılaştırıldığında benzer bir sorun vardır. Normal posix zamanlayıcılar için kullanıcı alanına yalnızca geçici olarak -ESRCH döndürür, ancak do_cpu_nanosleep() içindeki kullanım durumu için aynı UAF söz konusudur, yalnızca k_itimer yığında tahsis edilir. Ayrıca posix_cpu_timer_rearm() zamanlayıcıyı yeniden kurmayı başaramaz, bu da süresinin dolmayı durdurduğu anlamına gelir. Çözümler tartışılırken Frederic başka bir soruna dikkat çekti: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); Zayıf sıralı mimarilerde, p->sighand NULL olarak gözlemlendiğinde posix_cpu_timer_del()'in posix_cpu_timers*_exit() içindeki depoları gözlemleyeceği garanti edilmez, bu da WARN()'ın yanlış pozitif olabileceği anlamına gelir. Bu sorunları şu şekilde çözün: 1) __exit_signal() içindeki depoyu smp_store_release() olarak değiştirme. 2) lock_task_sighand()'in !sighand yoluna bir smp_acquire__after_ctrl_dep() ekleme. 3) Görevi arayan ve sighand'i kilitleyen, sighand == NULL olduğunda dönmeyen bir yardımcı fonksiyon oluşturma. Bunun yerine görev aramasını yeniden dener ve yalnızca bu başarısız olursa vazgeçer. 4) Bu yardımcıyı etkilenen üç fonksiyonda kullanma. #1/#2, sighand == NULL gözlemleyen okuyucu tarafın aynı zamanda önceki tüm depoları, yani posix_cpu_timers*_exit() içindeki depoları ve unhash_task() içindekileri de gözlemlemesini sağlar. #3, yukarıda açıklanan lider olmayan exec() durumunun sorunsuz şekilde ele alınmasını sağlar. Görev araması eski lideri döndürdüğünde ancak sighand == NULL olduğunda yeniden dener. Lider olmayan exec() durumunda, sonraki görev araması #1/#2 sayesinde yeni lideri gözlemleyecektir. Normal exit() senaryolarında sonraki arama başarısız olur. Görev araması başarısız olduğunda, fonksiyon ayrıca zamanlayıcının hâlâ kuyrukta olup olmadığını kontrol eder ve durum buysa bir uyarı verir. Ne yazık ki bu konuda yapılabilecek bir şey yoktur, ancak görev artık görünür olmadığından zamanlayıcıya artık erişilmemelidir. Bu kontrol ayrıca bellek sıralaması gerektirir ve bu, ilk arama başarısız olduğunda sağlanmaz. Bunu başarmak için kontrolün önüne, __exit_signal() içindeki write_seqlock() içindeki smp_wmb() ile eşleşen bir smp_rmb() eklenir. Bu, posix_cpu_timers*_exit() içindeki depoların görünür olmasını sağlar. Lider olmayan exec() sorununun geçmişi, zamanlayıcıda grup lideri görevine bir işaretçi saklayan posix CPU zamanlayıcılarının ilk günlerine kadar uzanır. Bu, lider olmayan bir exec() lideri değiştirdiğinde açıkça başarısız olur. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") 2010'da bunun için geçici bir çözüm ekledi ve bu çözüm hayatta kaldı ---kısaltıldı---