CVE-2026-93241

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: memcg: oom_reaper işlemi tamamlandıktan sonra ölmekte olan görevler için geri kazanım ve oom killer mekanizmasını atla Meta'da, OOM tarafından sonlandırılan bir işin birkaç saat boyunca çıkış yolunda takılı kaldığı durumlar gözlemlenmektedir. Belirli bir vakada, iş 8 saatten fazla takılı kalmış ve işlemin çıkış yapabilmesi için memory.max limitlerinin manuel olarak kaldırılması gerekmiştir. Söz konusu iş tek bir işlemden oluşmaktaydı; yaklaşık 55 GiB memory.max değerine sahipti ve zswap etkindi. Bellekte neredeyse hiç anonim sayfa yoktu ve zswap havuzunda ~51 GiB'a sıkıştırılmış ~111 GiB veri bulunuyordu (yani memory.current'ın neredeyse tamamı zswap idi). Geri kazanılacak hiçbir LRU öğesi kalmamıştı. Yapılan incelemelerde, bu işlemin yaklaşık 20 bin kanalının (thread) şu yığın (stack) ile takıldığı görülmüştür: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ek olarak, dmesg kayıtları "Out of memory and no killable processes..." mesajlarıyla dolmuştur. oom reaper'ın işlemi neden temizleyemediği veya eşlemesini (unmap) yapamadığı bilinmemektedir. Tahminim, oom reaper'ın mmap_lock kilidini okuma modunda sınırlı sayıda kez almaya çalışıp ardından vazgeçmesi nedeniyle, o sırada işlemin bir kanalının mmap_lock kilidini yazma modunda tutmuş olabileceği yönündedir. İlk şüphem, futex_cleanup ve çekirdek sayfa hatasının sonsuz hata ve yükleme denemelerine neden olmasıydı ancak benzer bir sorun üzerine yapılan önceki tartışmalarda [1] bu ihtimal elendi. Mevcut teorim ise bunun sadece oom_lock arkasında basit ve yavaş bir serileştirme olduğudur. Sayfa ayırıcının aksine, memcg yükleme kodu oom_lock kilidini "try" kullanmadan alır. Memcg OOM kodu mutex_lock_killable() kullansa da, çağrı yığındaki get_signal() fonksiyonunun do_group_exit() çağrısından önce SIGKILL sinyalini tükettiğine dikkat edilmelidir. Bu nedenle buradaki mutex_lock_killable() aslında bir mutex_lock() gibi davranır. Sonuç olarak on binlerce kanal oom_lock üzerinde beklemektedir ve sırayla futex temizleme kodundaki get_user() üzerinden -EFAULT alarak çıkmaktadırlar. [1]'deki tartışmalar, ölmekte olan görevleri tam olarak oom_reaper'ın onların mm yapısını temizleyebilmesi ve belleği asenkron olarak boşaltabilmesi için OOM yoluna yönlendiren a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") commit'ine yol açmıştır. Ancak reaper "best-effort" mantığında çalışır ve tek seferliktir: Eğer mmap_lock kilidini okuma için alamazsa (örneğin kardeş bir kanal bunu yazma için tutuyorsa), MMF_OOM_SKIP bayrağını ayarlar ve bir daha denemez; geriye sadece çok yavaş ilerleyen oom_lock serileştirmeli senkron tahliye kalır. MMF_OOM_SKIP ayarlandığında, ilgili mm için artık asenkron geri kazanım gerçekleşmez, dolayısıyla buna karşı yükleme yapan ölü bir görevin bekleyecek bir şeyi kalmaz: Belleğini yalnızca çıkış işlemi tamamlandığında boşaltır. Bu durumda geri kazanımı ve (kurbanı olmayan) OOM killer'ı çalıştırmak anlamsızdır ve bunu on binlerce çıkan kanal için yapmak onları oom_lock arkasında serileştirir. Bu nedenle, geri kazanım öncesinde eğer mevcut süreç, reaper işlemi tamamlanmış bir OOM kurbanıysa, yükleme başarısız kılınmalıdır. Her biri kendi zswapped sayfasında sağlam bir futex başlığı park eden 20 bin kanal ile yeniden üretilmiştir; bir kardeş kanal mmap_lock kilidini yazma için tutarken OOM-group-killed uygulanmış, böylece reaper vazgeçmiş ve MMF_OOM_SKIP bayrağını ayarlamıştır. next-20260728 ve baseline sürümlerinde test edildiğinde çıkış süresi yaklaşık 90 saniye iken, yama ile bu süre yaklaşık 3 saniyeye düşmüştür.