CVE-2026-98256

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: signal: exec() yarış durumunun önlenmesi Hyunwoo şu KASAN serbest bırakıldıktan sonra kullanım (UAF) hatasını ayıklamıştır: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 Hyunwoo'nun açıkladığı üzere bunun lider olmayan bir exec() ile gerçekleştiği ortaya çıkmıştır: de_thread(), release_task(leader) işleminden önce exchange_tids() fonksiyonunu çağırır; bu nedenle liderin tid'sine karşı oluşturulan bir SIGEV_THREAD_ID zamanlayıcısı tarafından tutulan struct pid artık execve() fonksiyonunu çağıran iş parçacığını işaret eder. pid_task() bu iş parçacığını döndürür ve üzerindeki lock_task_sighand() işlemi başarılı olur. Zamanlayıcı sinyali engellenmişse, sigqueue yapısı liderin task::pending kuyruğunda beklemeye devam eder. Bu zamanlayıcının bir sonraki sona erme işlemi, release_task() kuyruğu temizlerken çalışabilir. posixtimer_send_sigqueue(), sigqueue'nun zaten kuyrukta olup olmadığını yalnızca list_head::next değerini okuyan basit bir list_empty() ile kontrol eder. list_del_init() atomik değildir ve INIT_LIST_HEAD() list_head::prev'den önce list_head::next değerini saklar, bu nedenle kontrol bu arada geçebilir. list_add_tail(), girişi canlı iş parçacığının task::pending kısmına ekler ve ardından temizleme işleminin list_head::prev kaydı, list_add_tail()'ın az önce ayarladığı list_head::prev bağlantısının üzerine yazar. __flush_itimer_signals() bunu da geri almaz. list_head::prev girişin kendisine işaret ettiğinde, list_del_init() yalnızca aynı değerleri tekrar saklar, böylece giriş listeden kaldırılmaz. Son referans bırakılıp zamanlayıcı RCU tarafından serbest bırakıldıktan sonra hala orada durur ve daha sonraki bir tgkill()'ın list_add_tail() işlemi, o list_head::prev üzerinden serbest bırakılmış zamanlayıcıya ulaşır. Bu sorun, sigqueue temizleme işlemini sighand kilidinin tutulduğu bölgenin dışına taşıyan son commit ile ortaya çıkmıştır. Hyunwoo bunu list_del_init_careful() kullanarak düzeltmeyi önermiştir ancak bu sadece sorunun üzerini örtmektedir. Bazı tartışmalar ve çözüme yönelik çeşitli denemelerin ardından Eric, release_task() aşamasında geç bir zamanda task::pending'in temizlenmesi için hiçbir neden olmadığını ve bunun zaten exit_signals() içinde yapılması gerektiğini belirtmiştir. Ölmekte olan bir görevin bekleyen kuyruğuna eklenen sinyalleri toplayıp iletecek hiçbir yapı olmadığından, bunu daha fazla geciktirmek için bir neden yoktur. Ancak, bu noktadan sonra içeriye hiçbir sinyal kuyruklanamayacağından emin olunmalıdır. exit_signals(), task::flags içinde PF_EXITING bayrağını ayarlar ve bu, gösterge olarak kullanılabilir. Çözüm şöyledir: - Görevin PF_EXITING bayrağı ayarlı olduğunda, __send_signal_locked() ve posixtimer_send_sigqueue() fonksiyonlarında görev özel sinyalleri (PIDTYPE_PID) için sinyal kuyruğa eklemesini önlemek. - Görev grubu boş olduğunda ve grup çıkış durumu için exit_signals() içindeki kilitlenmemiş PF_EXITING ayarını sighand kilidi ile korumak. - task::pending sinyallerini tam burada temizlemek. Bunu, tüm bekleyen listesini sighand kilidi altında yığın tabanlı (on-stack) bir liste başına taşıyarak ve sinyalleri kilit tutulmadan serbest bırakarak optimize etmek. Kilitsiz temizleme ve zayıf sıralı sistemlerde lider olmayan exec durumu hakkında oldukça fazla tartışma yapılmıştır. Sorun, bir posix zamanlayıcı sinyali göndermeye çalışan üçüncü bir tarafın hedef görevi bulmak için PID aramasına güvenmesidir ve sinyal başlangıçta eski lidere yönlendirildiğinde bu arama yeni liderle sonuçlanabilir. Sinyalin eski lidere kuyruklanmış olması durumunda, kilitsiz temizleme şu durumla ilgili endişeleri artırmıştır: old_leader new_leader third party A: flush_list() // list_del_in ---kesildi---