GhostLock: 15 yıl boyunca tüm Linux dağıtımlarında bulunan stack UAF

• GhostLock (CVE-2026-43499), Linux 2.6.39’da eklenip 7.1’de düzeltilen bir kernel açığıdır; ayrıcalıksız yerel bir saldırgan, yalnızca sıradan thread sistem çağrılarıyla stack UAF oluşturarak bunu root yetkisi elde etme ve container’dan kaçma için kullanabilir
• Requeue-PI proxy yolundaki remove_waiter(), gerçek bekleyen task yerine currentın pi_blocked_on alanını temizlediği için, kullanıcı alanına dönen task’ta serbest bırakılmış bir stack frame’ini gösteren pointer kalır
• Üç futex ve üç thread ile bir PI bağımlılık döngüsü oluşturularak -EDEADLK rollback’i tetiklenir; PR_SET_MM_MAP’in kontrol edilebilir stack buffer’ında sahte bir rt_mutex_waiter kurularak kısıtlı pointer yazma elde edilir
• Exploit, prefetch ile KASLR ve physmap taban adreslerini bulur; CPU entry area’da (CEA) sahte yapılar ve ROP stack’i yerleştirdikten sonra inet6_protos[IPPROTO_UDP] değerinin üzerine yazarak IPv6 UDP loopback paketiyle kontrol akışını ele geçirir
• Araştırmacılar, %97 kararlı yetki yükseltme ve container’dan kaçma exploit’iyle Google kernelCTF’ten 92.337 dolar aldı; yamalanmamış tüm Linux dağıtımları en güncel LTS’ye yükseltilmelidir

---

Etki kapsamı ve açığın özeti

• GhostLock, VEGA tarafından keşfedilen bir Linux kernel açığıdır; yerel ayrıcalıksız bir kullanıcı tarafından ek yetki veya kullanıcı namespace’i olmadan tetiklenebilir
• 8161239a8bcc ile yapılan rtmutex yeniden çalışması sırasında eklendi; etki kapsamı v2.6.39-rc1 ile v7.1-rc1 arasıdır
• Nisan 2026’da 3bfdc63936dd ile düzeltildi; gereken tek kernel ayarı CONFIG_FUTEX_PI=y’dir
• Saldırgan şu süreçle yetkisini yükseltebilir
  • Yalnızca sıradan thread sistem çağrılarıyla kernel stack belleğini gösteren dangling kernel pointer elde eder
  • Neredeyse keyfi bir adrese pointer veya 8 baytlık sıfır yazabilen kısıtlı bir primitive oluşturur
  • Bir fonksiyon tablosunu ele geçirerek kontrol akışını devralır ve root yetkisi elde eder
• Yamalanmamış tüm Linux dağıtımları etkilendiğinden en güncel LTS sürümüne yükseltilmelidir

remove_waiter() neden yanlış task’ı temizliyor?

• kernel/locking/rtmutex.c içindeki remove_waiter(), aslında bloklanmış thread’in kendi bekleme durumunu doğrudan temizlediği yol için yazılmıştır
• Normal slow path’te çalışmakta olan current, waiter’ın sahibi olan task olduğundan current->pi_blocked_on alanını temizlemek doğru davranıştır
• Requeue-PI proxy yolunda ise rt_mutex_start_proxy_lock(), başka bir uyuyan task adına rt_mutex_waiter’ı kuyruğa ekler ve hata oluşursa bunu geri alır
  • Bu sırada current, FUTEX_CMP_REQUEUE_PI çağıran requeuer’dır
  • Gerçek waiter ise FUTEX_WAIT_REQUEUE_PI içinde uyuyan ayrı bir task’tır
• __rt_mutex_start_proxy_lock() -EDEADLK döndürdüğünde remove_waiter(), waiter’ı lock’tan kaldırırken yalnızca current->pi_blocked_on alanını NULL yapar
• Gerçek waiter’ın pi_blocked_on alanı, kendi kernel stack’indeki rt_mutex_waiter’ı göstermeye devam eder; waiter kullanıcı alanına döndüğünde bu stack frame’i serbest bırakılmış kabul edilir
• Daha sonra PI chain araması bu task üzerinden geçtiği anda serbest bırakılmış stack nesnesini dereference eder
• lockdep yalnızca hangi pi_lockın tutulduğunu kontrol eder; bunun kimin lock’ı olduğunu denetlemediği için bu hatayı yakalayamaz

-EDEADLK rollback’i oluşturan üç futex döngüsü

• Hata yoluna ulaşmak için üç futex ve üç thread ile bir PI bağımlılık döngüsü kurulur
  • f_pi_chain: waiter’ın önce kilitlediği PI futex
  • f_pi_target: owner’ın önce kilitlediği ve requeue hedefi olan PI futex
  • f_wait: waiter’ın FUTEX_WAIT_REQUEUE_PI ile beklediği normal futex
• Tetikleme sırası şöyledir
  1. waiter f_pi_chain’i kilitledikten sonra FUTEX_WAIT_REQUEUE_PI(f_wait -> f_pi_target) içinde bloklanır ve rt_mutex_waiter kendi kernel stack’ine yerleşir
  2. owner f_pi_target’ı kilitledikten sonra waiter’ın tuttuğu f_pi_chain üzerinde bloklanır
  3. main thread FUTEX_CMP_REQUEUE_PI(f_wait -> f_pi_target) çağırır
• Proxy requeue, waiter’ı f_pi_targeta bağlamaya çalıştığında waiter → f_pi_target → owner → f_pi_chain → waiter döngüsü kapanır
• PI chain araması -EDEADLK döndürür ve hatalı rollback’i çalıştırır; bunun sonucunda waiter, dangling pi_blocked_on ile uyanır
• Kritik koşul, waiter hâlâ stack nesnesini tutarken requeuer’ın rollback yapmasıdır; döngü tamamlandıktan sonra süreç kendi kendine ilerler
• waiter kullanıcı alanına döndüğünde artık zaman baskısı yoktur; daha sonra istenen herhangi bir anda sched_setattr() ile chain araması tetiklenebilir
• Kurulumda üç thread kullanılsa da UAF yarışı tek CPU çekirdeğinde bile tetiklenebilir

Stack UAF’nin sağladığı ilk primitive

• Dangling pointer, önceki FUTEX_WAIT_REQUEUE_PI frame’inde bulunan rt_mutex_waiter’ı gösterir
• Aynı task’ın aynı stack derinliğine kontrol edilebilir baytlar yeniden yerleştirilirse, kernel’in bunu sahte bir rt_mutex_waiter olarak dereference etmesi sağlanabilir
• Sahte yapının nasıl yerleştirildiğine bağlı olarak tek bir erişimde iki ana primitive elde edilir
  • Kısıtlar altında neredeyse keyfi bir adrese pointer yazılabilir
  • Kısıtlar altında neredeyse keyfi bir adrese 8 baytlık sıfır yazılabilir
• Yazmadan önce birden fazla pointer dereference işlemi ve bütünlük kontrolü yapılır; ancak koşullar sağlanırsa yazma sonrasında da kernel çökmeden normal şekilde geri döner
• Exploit’i tamamlamak için stack frame yeniden kullanımı, sahte waiter’ın yapı kontrollerinden geçmesi ve yazma kısıtlarını karşılayan bir hedef seçilmesi gerekir

PR_SET_MM_MAP ile serbest bırakılmış stack frame’i yeniden kullanma

• waiter, futex sistem çağrısından döner dönmez prctl(PR_SET_MM, PR_SET_MM_MAP, ...) çağırır
• prctl_set_mm_map(), kullanıcının sağladığı auxv’yi sabit boyutlu stack buffer’ı unsigned long user_auxv[AT_VECTOR_SIZE] içine kopyalar
• Bu buffer, serbest bırakılmış waiter’a benzer bir stack derinliğinde yer aldığından, büyük ve hizalanmış, kontrol edilebilir bir qword bloğu önceki rt_mutex_waiter’ın üzerine biner
• auxv’nin çakışan alanı şu şekilde yapılandırılır
  • tree: silme sırasında seçilen child pointer W0_BASE’i tree root’a çıkaran bir rb node yapılır
  • task: zincir taramasındaki dereference’ların güvenle geçmesi için &init_task olarak ayarlanır
  • lock: yazma hedefini denk getirmek için &inet6_protos[IPPROTO_UDP] - 8 olarak belirtilir
  • wake_state: 0 olarak ayarlanır
• auxv memfd’ye konur ve kopyalama sayfa sınırını aşacak şekilde yerleştirilir; ardından kardeş thread, prctl çalışırken arka sayfaya fallocate(PUNCH_HOLE) yarışı sokarak copy_from_user süresini uzatır
• Başka bir CPU’daki consumer thread, sahte waiter stack’te kalırken waiter üzerinde sched_setattr() çağırarak PI zincirini tarar
• clone, setsockopt, pselect, keyctl gibi kontrol edilebilir büyük stack yerel değişkenleri kullanan diğer sistem çağrıları da aynı rolü oynayabilir
• prctl, buffer’ı büyük ve hizalanmış olduğu ve namespace gerektirmediği için seçildi; ek adaylar açık PoC kodunda yer alıyor

rb-tree silme ile kısıtlı pointer yazımı oluşturma

• Sahte waiter kontrol edilse bile hemen tam anlamıyla rastgele yazma elde edilmez; zincir taraması şu yolu yürütür
  • task->pi_blocked_on içinde sahte waiter’ı bulur
  • fake waiter->lock üzerinden sahte rt_mutex_base’i bulur
  • rt_mutex_dequeue(lock, waiter), lock->waiters üzerinde rb-tree silme işlemi yapar
• Yalnızca tek child’ı olan root node silindiğinde bu child’ın root slot’una yazılması özelliğinden yararlanılır
• lock, target - 8 olarak belirtilirse çevredeki veri aşağıdaki rt_mutex_base alanları olarak yorumlanır
  • target - 8: kilitli değilmiş gibi okunması gereken wait_lock
  • target: üzerine yazılacak waiters.rb_root.rb_node
  • target + 8: waiters.rb_leftmost
  • target + 16: owner
• Sonuçta çalıştırılan tekil yazma *(uint64_t *)target = W0_BASE olur
• Hedef adres kabaca şu koşulları sağlamalıdır
  • target - 0x08’in alt 32 biti 0 olmalı
  • target + 0x08’deki 64 bitlik değer 0 olmalı
  • target + 0x10’daki owner pointer’ında alt flag’ler çıkarıldıktan sonraki değer 0 olmalı
• Öndeki qword kilitli bir spinlock gibi görünürse trylock başarısız olur ve hiçbir şey yazmadan çıkar
• Arkadaki değer kontrol edilmeyen bir top waiter’a veya owner’a işaret ederse ya da eşlenmemiş bir değer olursa kernel panic oluşabilir
• W0_BASE, karşılaştırma, yeniden kuyruğa alma, öncelik güncelleme ve owner’sız wakeup bitene kadar geçerli kalması gerektiğinden CEA’nın direct-map alias’ı kullanılır

prefetch sızıntısı ve CPU entry area

• KASLR·physmap taban adresini bulma

  • Belirli bir adres için prefetch çalışma süresi, o adresin mevcut page table’da map edilip edilmediğine göre değişir
  • Yetkisiz bir process kernel adres aralığındaki çalışma sürelerini ölçerse mapping konumunu tahmin edebilir; ayrıntılı prensipler prefetch makalesinde özetlenmiştir
  • Varsayılan Linux kernel image taban adresinin entropisi yaklaşık 9 bit olduğundan, tekrarlı ölçümlerle KASLR taban adresi neredeyse %100 güvenilirlikle geri kazanılır
  • Teorik olarak prefetch bulunan ve uygun KPTI bulunmayan CPU’lar etkilenir; pratikte ise bu teknik çoğunlukla KPTI’nin kapalı olduğu x86’da kullanılır
  • kernelCTF image’ında KPTI kapalıdır; KPTI açık olsa bile prefetch ile EntryBleed birleştirilirse trampoline üzerinden kernel image taban adresi geri kazanılabilir

• CEA adres rastgeleleştirmesini aşma

  • CPU entry area (CEA), giriş ve exception işleme stack’leri ile register context’lerini tutan, x86’da CPU başına bir yapıdır
  • Yetkisiz bir program yazılımsal exception tetiklediğinde kendi register context’ini CEA exception stack’indeki pt_regs alanına yazar ve yaklaşık 120 baytlık ardışık, kontrol edilebilir bellek oluşturabilir
  • Linux 6.2’den önce CEA sanal adresi tamamen sabitti; sahte yapılar, pointer dereference yan etkilerini soğurma ve ROP stack’i kurma için doğrudan kullanılabiliyordu
  • Project Zero’nun Bringing back the stack attack yayınının ardından Linux 6.2’den itibaren CEA sanal adresi güçlü şekilde rastgeleleştirildi
  • Her CPU’nun CEA sanal adresi farklı şekilde rastgeleleştirilir, ancak fiziksel adres sabit olduğundan physmap taban adresi bilinirse direct-map alias’ı hesaplanabilir
  • prefetch, aday sınır normalizasyonu ve beklenen CEA sayfa kontrolü birleştirilerek çevredeki alias’lar elenir ve cea_direct = physmap_base + CPU1_CEA_BASE elde edilir
  • kernelCTF LTS 6.12.80’in 3,5 GB’lık boot ortamında ilgili offset 0x11c517000(+0x1f58)’dir

CEA’yı sahte waiter ve takip eden nesneler olarak yeniden kullanma

• İlk yazmadan önce CEA’daki W0 alanına kendi içinde tutarlı bir sahte waiter ve lock yerleştirilir
  • task, &init_task olarak ayarlanır
  • prio için geçerli bir değer konur
  • lock’un wait_lock alanı kilitli değilmiş gibi görünecek hale getirilir
  • owner, dequeue, yeniden kuyruğa alma, öncelik güncelleme ve wakeup aşamalarını güvenle geçecek şekilde yapılandırılır
• rb-tree yazımı tamamlandıktan sonra W0 artık waiter olmak zorunda değildir; üzerine yazılan hedefin gerektirdiği yapı ile CEA yeniden doldurulabilir
• CEA yaklaşık 120 baytla küçüktür, ancak hesaplanabilir sabit bir kernel adresine veri yerleştirmeyi sağladığı için verimlidir
• NPerm ve kernelsnitch gibi öğeler daha geniş bir alanda aynı rolü üstlenebilir
• Exploit, tek bir CEA bölgesini sahte rt_mutex_waiter, sahte lock, inet6_protocol, JOP ve stack pivot slot’ları, son ROP stack’i olarak sıralı veya eşzamanlı biçimde kullanır

inet6_protos[IPPROTO_UDP] ile denetim akışını ele geçirme

• Tipik bir x86_64 Linux’ta KASLR taban adresi elde edildikten sonra, koşullara uyan bir fonksiyon tablosunun ya da onu içeren bir nesnenin üzerine yazan kısa bir yol seçilebilir
• Yazılabilir veri alanındaki inet6_protos[IPPROTO_UDP] çevresi, gerekli kısıtları doğal biçimde karşılar
  • inet6_protos[16] == NULL, sahte wait_lock için kilitli olmayan durum olur
  • inet6_protos[17] == &udpv6_protocol, gerçekten üzerine yazılacak hedeftir
  • inet6_protos[18] == NULL, sahte rb_leftmost olur
  • inet6_protos[19] == NULL, sahte owner olur
• Yazma tamamlandığında inet6_protos[IPPROTO_UDP], CEA sayfası içindeki sahte inet6_protocolü işaret eder
• CEA yeniden püskürtülerek yapı şu şekilde düzenlenir
  • handler: ilk pivot gadget’ı olarak belirlenir
  • err_handler: kullanılmaz
  • flags: INET6_PROTO_NOPOLICY | INET6_PROTO_FINAL olarak ayarlanır
• ::1 adresine connect ettikten sonra veri yazan bir IPv6 UDP loopback paketi gönderildiğinde çekirdek sahte handlerı çağırır ve program sayacını kontrol etmeyi mümkün kılar

Kısa pivot ve DirtyMode ile yetki yükseltme

• Google kernelCTF’nin lts-6.12.80 hedefinde uygun tekil bir stack pivot gadget’ı bulunamadığından, ek bir load/call ile CEA adresi rbp içine konduktan sonra mov rsp, rbp; pop rbp; ret ile pivot yapılır
• ret2usr ya da /proc/%P/fd/x üzerine tamamen yazma, yaklaşık 10 gadget qword’u gerektirdiği için sınırlı CEA alanına göre fazla büyüktür
• Son aşamada, tek bir yazmayla yetki bitlerini değiştirip kalan süreci kullanıcı alanında yürüten DirtyMode kullanılır
• Yazma hedefi, çekirdek verilerindeki coredump_sysctls[1].mode, yani core_pattern sysctl’inin erişim modudur
• Çekirdek imajıyla aynı KASLR kaymasını paylaştığı için adres hesaplanabilir; yazma biti olan sondan ikinci bitin set edilmiş olduğu bir değer yeterlidir
• Kısa bir pop reg; mov [reg], reg; ret zinciriyle mod değeri değiştirilir ve ele geçirilen iş parçacığı msleep ile güvenli biçimde durdurulur
• /proc/sys/kernel/core_pattern tüm kullanıcılar tarafından yazılabilir hale geldiğinde, yetkisiz bir süreç |/proc/%P/fd/666 %P yazar ve helper’ı çökertir; böylece çekirdek saldırganın ikilisini root yetkileriyle çalıştırır
• İlk rb-tree yazması, hizalama/yerleşim kısıtları nedeniyle coredump_sysctls[1].mode adresine doğrudan ulaşamadığından, mod değişikliği kısa ROP aşamasında yapılır

Tam exploit akışı ve sonuç

• Saldırı şu sırayla ilerler
  1. prefetch ile çekirdek imajı kayması ve physmap taban adresi sızdırılır
  2. GhostLock ile waiter’ın pi_blocked_on alanında dangling rt_mutex_waiter bırakılır
  3. PR_SET_MM_MAP ile aynı çekirdek stack frame’i yeniden kullanılarak sahte waiter oluşturulur
  4. rtmutex rb-tree silme işlemi kullanılarak inet6_protos[IPPROTO_UDP] içine CEA işaretçisi yazılır
  5. CEA’ya sahte inet6_protocol, pivot slotu ve ROP stack’i yerleştirilir
  6. IPv6 UDP loopback paketiyle üzerine yazılmış handler çağrılır
  7. DirtyMode ile core_patternın mod biti değiştirilir ve yetki yükseltme kullanıcı alanında tamamlanır
• kernelCTF uzak ortamında CEA ve DirtyMode’u birleştiren yol yaklaşık 5 saniyede bayrağı elde etti
• Tam exploit CyberMeowfia projesinde yayımlanmış durumda
• Android’de stack frame’inin yeniden kullanımı ve ASLR·CFI atlatma yöntemleri farklılaşır; bunlar ayrı bir devam yazısında ele alınacak

Alternatif yollar ve hafifletmeler

• Daha büyük ROP alanı

  • NPerm tabanlı bellek, denetim akışı ele geçirildikten sonra büyük bir sahte stack olarak kullanılabilir
  • Lukas Maar’ın heap-KASLR sızıntısı gibi daha ağır yollar da mümkündür, ancak ek aşamalar nedeniyle çalışma süresi uzar
  • kernelCTF’de en kısa ve en güvenilir zincir avantajlı olduğundan CEA ve DirtyMode kombinasyonu kullanılır

• Çekirdek yaması

  • Nihai yama, current yerine waiter->task temel alınarak pi_lock alır ve pi_blocked_on alanını temizler
  • remove_waiter(), waiter_task = waiter->task değerini kaydettikten sonra şu sırayla işlem yapar
    1. waiter_task->pi_lock kilitlenir
    2. waiter rtmutex kuyruğundan kaldırılır
    3. waiter_task->pi_blocked_on = NULL olarak ayarlanır
    4. Sonraki rt_mutex_adjust_prio_chain() çağrısına da current yerine waiter_task geçirilir
  • Araştırmacıların v1’den önce gönderdiği ayrı düzeltme önerisi, çağıranın sahip task’ı açıkça ileteceği şekilde yapılandırılmıştır
    • Kendi kendisinin bloklandığı yollarda current iletilir
    • Proxy rollback’te proxy hedefi olan task geçirilir
    • pi_blocked_on hâlâ ilgili waiter’ı gösteriyorsa temizlenir ve task’ın pi_locku ile korunur

• RANDOMIZE_KSTACK_OFFSET

  • Exploit, serbest bırakılmış waiter frame’i ile sonraki user_auxv frame’inin deterministik olarak çakışmasına dayanır
  • RANDOMIZE_KSTACK_OFFSET açılırsa stack ofseti değişir ve bu aşama yaklaşık 1/32 olasılıklı 5 bitlik bir tahmine dönüşür
  • Gönderilen iki genel hedefte bu ayar varsayılan olarak kapalıydı; hafifletme hedefinde ise açık olduğundan bu exploit yolu kullanılmadı

• STATIC_USERMODE_HELPER

  • STATIC_USERMODE_HELPER bu belirli DirtyMode yolunu engeller
  • Ancak erişim izninin ctl_table::mode ile denetlendiği ve tablonun tahmin edilebilir, yazılabilir çekirdek verilerinde bulunduğu başka /proc/sys ayarlarında aynı yöntem genelleştirilebilir

Açıklama takvimi

• 18 Nisan 2026: Zafiyet ve taslak yama [e-mail] adresine iletildi
• 20 Nisan 2026: Zafiyet başka bir yamayla düzeltildi
• 4 Mayıs 2026: Düzeltme v1’i geriye dönük olarak uygulandı
• 30 Haziran 2026: Google, kernelCTF gönderimini doğruladı
• 7 Temmuz 2026: Teknik analiz yayımlandı
• VEGA’nın bulduğu zafiyete standart 90+30 gün açıklama politikası uygulandı

[GN⁺]

Hacker News yorumları

• Android 9·13·16 ve farklı Firefox 150 öncesi sürümlerini kullanan 3 cihazda test ettim; 2’si boot loop’a girip kurtarma moduna alınmak zorunda kaldı, kalan 1’inin ise gücü kesildi. Demo, desteklenen Pixel cihazlarında duvar kağıdını değiştiriyor; test sayfasına IonStack üzerinden bakılabilir
  Kişisel cihazlarda bloglara ya da rastgele sitelere bakarken, ana tarayıcıdan ayrı olarak Chromite gibi Chromium tabanlı bir tarayıcı kurup, bayraklardan JavaScript’i ve sık hedef alınan donanım hızlandırmalı video kod çözücüsünü kapatmak, ardından bozulan sitelerde okuma modunu kullanmak daha güvenli. Alternatif olarak buna ayrılmış bir tablet de tutulabilir

  • Şu anda yalnızca Pixel 10’da test edildi, ancak başka cihazları desteklemeye yönelik birkaç PR açılmış durumda; bkz. https://github.com/NebuSec/CyberMeowfia
  • Çekirdek exploit’ini başka cihazlara taşımayı denerken, derleyicinin her çekirdek derlemesinde stack frame yerleşimini nasıl yaptığına karşı son derece hassas olduğu görüldü. Belirli bir derlemeye uygun stamp yöntemi ve ofsetler bulunduğunda oldukça kararlı çalışıyor
  • Riski göze alıp bunu Samsung S26 Ultra üzerinde çalıştırdım; adb kurup doğruladıktan sonra tüm sonuçları açıklayacağım
    Test sayfasına girince Firefox sekmesinde çıktı belirdi ve kavram kanıtı kodu çalışmış gibi göründü, ancak ardından telefon dondu ve tüm girdileri reddetti. Yalnızca yeniden başlatma işe yaradı; çekirdek donmuş gibi görünürken yeniden başlatma olayına nasıl yanıt verebildiğini merak ediyorum. Ekran, çalıştırma sonucunun bir kısmını göstermeye devam ederek açık kaldı, sonra ekran koruyucu devreye girdi
  • Henüz root edilemeyen Android cihazları root etmekte kullanılabilirse harika olurdu; bunun mümkün yolu nedir merak ediyorum
  • Firefox açığı, IonMonkey JIT derleyicisindeki bir type confusion olan CVE-2026-10702 gibi görünüyor: https://www.sentinelone.com/vulnerability-database/cve-2026-10702/

• Sadece exploit’i bulmakla kalmayıp, copyfail’den farklı olarak herkesin hemen kullanabileceği bir zero-day yerel ayrıcalık yükseltme betiği yayımlamayan güvenlik araştırmacılarına büyük övgü
  Rocky Linux 9 üzerinde saatlerce yerel ayrıcalık yükseltme (LPE) denedim ama neyse ki başarılı olamadım. Çok fazla zamanı ya da çok yüksek becerisi olmayan biri için kurumsal dağıtımlarda gerçek saldırıda kullanılması zor görünüyor

• Normalde bootloader kilidi açılamayan telefonlarda bile bu açıkla bootloader kilidini açmanın mümkün olup olmadığını merak ediyorum. Mümkünse Android ekosisteminde yaşanan en büyük olaylardan biri olabilir

• Başlığa yerel ayrıcalık yükseltmesini ifade eden LPE eklenseydi çoğu kişi içi rahatlayıp hafta sonuna dönebilirdi gibi geliyor

  • O kadar rahatlatıcı değil. Genelde yerel ayrıcalık exploit’leri, sıradan kullanıcı yetkisinden root yetkisine yükselmeyi ifade eder ve sıradan yetkilerdeki uygulamalar da zaten büyük zarar verebildiğinden bu genelde çok şaşırtıcı olmaz
    Ama bu saldırı, Firefox’un izole tarayıcı süreci gibi güçlü biçimde sandbox’lanmış süreçler içinde de tetiklenebiliyor. Saldırgan, bir JavaScript açığıyla izole sandbox içinde yerel kod çalıştırdıktan sonra bu açıkla çekirdek moduna kadar yükselen iki aşamalı saldırıyı birleştirebilir; bu yüzden hem Firefox’u hem de Linux çekirdeğini güncellemek gerekiyor
  • Üstteki yorumdaki saldırı, JavaScript’ten doğrudan root yetkisi alıyormuş gibi görünüyor ama aslında iki farklı exploit’i zincirliyor
  • Eğer container escape mümkünse hâlâ çok sayıda insanı etkileyebilir diye düşünüyorum
  • Firefox/IonMonkey’deki type confusion açığı da bulunduğundan, rastgele bir web sitesini ziyaret etmekle bile çok hızlı şekilde cihaz ele geçirilebilir
  • Artık bu tür durumlarda harcanmak üzere stokta yüzlerce zero-day varmış gibi geliyor. SSH’den Node.js’e kadar her birkaç haftada bir yeni sorun çıkıyor; tüm iletişimi WireGuard arkasına koymakla yetinmiyorsanız, neredeyse hepsine uzaktan açık muamelesi yapmak gerekecek gibi

• “Google, kernelCTF ödülü olarak 92.337 dolar ödedi” kısmı özellikle dikkat çekici

  • Etki alanı düşünülünce az bir miktar gibi görünüyor. Şirketler sadece uzaktan exploit’lere mi büyük para ödüyor merak ediyorum

• Bunun, Android uygulamalarının NDK ile yerel kod çalıştırıp root yetkisi alabileceği anlamına gelip gelmediğini ve SELinux’un savunmada işe yarayıp yaramadığını merak ediyorum

  • Amiral gemisi olmayan telefonlar, çekirdek dahil güncellemeleri nadiren aldığı için bunun pratikte mümkün olma ihtimali yüksek görünüyor
    Eski çekirdeklere yamaları backport etmek mümkün, ancak akıllı telefon güncelleme notlarında CVE’lerin açıkça belirtilmesi nadir olduğu için, zafiyet tarama araçları pratikte tek doğrulama yöntemi oluyor. Play Store’dan ya da dışarıdan alınan bir uygulama ele geçirilmişse anında root yetkisi kazanabilir; bu yüzden kurulum sırasında güven ve denetimi doğrulama ilkesi hâlâ önemli. Gelecekte bunun, tüm Google Play Integrity seviyelerine eklenip yaması yapılmamış telefonlara çeşitli uygulamaların kurulmasını engellemesi mümkün olabilir. Rastgele sitelerden ve reklamlardan kaçınmanın zor olduğu tarayıcılarda ise sandbox escape, uygulama izolasyonunu da aştığı için daha ciddi; iOS’taki JailbreakMe’ye benziyor
  • Çekirdeğin kendisi ele geçirilirse SELinux savunamaz. Android sandbox’ı ya da Docker gibi container teknolojileri de bu exploit’i engelleyemez; pratik bir izolasyon yöntemi olarak ancak tam sanallaştırma kalıyor. KVM kullanılıyorsa, geçen hafta yayımlanan CVE-2026-53359 yamasının her yere dağıtılmış olduğu varsayılmalı
    Son 15 yılda çıkan Linux sürümlerinde yerel kod çalıştırabilen herhangi bir uygulama, cihaza çekirdek güncellemesi gelene kadar root yetkisi elde edebilir

• GhostLock’un Linux 2.6.39’da eklenmiş olması ve ancak Linux 7.1’de düzeltilmesi sarsıcı

• Yorumları sanki dün okumuşum gibi geliyor ama yazım zamanı hepsinde 10 saatin altında görünüyor; HN’nin zaman gösterimi yanlış mı diye merak ediyorum

  • Muhtemelen HN’nin yeniden öne çıkarma (re-up) sistemi yüzünden. Bu yazı yeniden öne çıkarılırken mevcut yorumların zaman damgaları göreli zaman olarak yeniden hesaplandı; ilgili içerik için bkz. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20timestamps%20re-up&sort=byDate&type=comment
    Her gün bakılan “underwater” listesinde, yani çok oy almasına rağmen bir nedenle ana sayfaya çıkamayan gönderiler arasında bu yazı en üstteydi, bu yüzden yeniden öne çıkarıldı. Garip görünüyor ama bundan daha az kafa karıştırıcı bir alternatif henüz bulunmuş değil
  • Benzer haberler tek başlık altında birleştirilirken yorumlar da birleştirilebiliyor