Linux çekirdeği güvenlik açıkları dağıtımlara önceden bildirilmiyor

• Linux çekirdeğindeki yerel yetki yükseltme açığı CopyFail, son dönemdeki çekirdeğin “make-me-root” (normal kullanıcıyı root yapan) açıkları arasında en ciddi sınıfa giriyor
• Bu açık, çekirdek sürümü 4.14 içindeki belirli bir commit ile eklendi ve CopyFail’in kullandığı authencesn modülüne in-place optimizasyonun eklendiği zamanla örtüşüyor
• Düzeltme, çekirdek 6.18.22, 6.19.12 ve 7.0 sürümlerine işlendi; 6.18.22 ve 6.19.12 ise düzeltmenin 11 Nisan’da backport edilmesiyle yayımlandı
• Ancak hâlâ yaygın olarak kullanılan Longterm çekirdeklerde (6.12, 6.6, 6.1, 5.15, 5.10) bu düzeltme yer almıyor ve upstream stable queue’da da henüz görünmüyor
  • Sorun 2017’de eklendiği için bu eski Longterm çekirdeklerin de etkilenip etkilenmediğinin doğrulanması gerekiyor
• İlgili düzeltme yaması eski çekirdeklere clean apply (kod çakışması olmadan temizce uygulanma) olmuyor ve bazı API değişiklikleri nedeniyle backport denemeleri de güvenle ilerletilemiyor
• Acil müdahale gerektiren ortamlarda geçici önlem olarak IPSec’in authencesn modülünü devre dışı bırakan bir yama uygulanabilir; IPSec uzmanı olunmasa bile bu, “mükemmel değil ama daha az kötü bir seçenek” sayılıyor
• Yani yapısal sorun, Linux çekirdeği güvenlik açıklarının açıklanma sürecinin kendisinde yatıyor:
  • Linux çekirdeği açıkları, açığı bildiren kişi doğrudan linux-distros mailing list’e (dağıtım güvenlik ekiplerinin bulunduğu kapalı kanal) iletmediği sürece, dağıtımlara önceden bildirim gitmeyecek şekilde işliyor
  • Bu CopyFail olayında da linux-distros ML üzerinden ön uyarı (heads-up) yapılmadı
  • Sonuç olarak Ubuntu·RHEL·SUSE gibi büyük dağıtımların güvenlik ekipleri, açık kamuya açıklanmadan önce yama hazırlama fırsatı bulamadı

[unsure4000]

Blog yazısı biraz çocukça olsa da, bunun basitçe itici olmanın ötesinde bir hata olarak değerlendirilmesindense, daha büyük kusurun sistemsel bir sorun olduğunu düşünüyorum.

[GN⁺]

Hacker News görüşleri

• Bağlantı verilen yazının yazarı Sam James bir Gentoo geliştiricisi
  Her hâlükârda bu neredeyse felaket düzeyinde ve dağıtımlar düzeltmeleri yayımlamadan önce exploit’in açıklanması son derece sorumsuzcaydı
  Bunun yüzünden ne kadar çok shared hosting sağlayıcısının hacklendiğini bilmek mümkün değil
  Ayrıca kernel security team ile dağıtım maintainer’ları arasında iletişim yok gibi görünmesi de endişe verici
  İnsan ilkinin ikincilere haber vereceğini varsayıyor ama pratikte sorumluluğun açığı bulan kişide olduğu bir yapı varmış gibi duruyor

  • Bildirilen tarafa yama girdikten 30 gün sonra açıklama yapılmasında bence sorun yok
    Bilgi olsun diye, Google Project Zero da benzer bir “90+30” politikası kullanıyor: https://projectzero.google/vulnerability-disclosure-policy.h...
    Asıl sorun, kernel security team ile dağıtım maintainer’ları arasında bir iletişim kanalı olmaması
    Açığı bulan kişi tüm downstream’lere tek tek bildirmekle yükümlü olmamalı
    Kernel ekibi dağıtım güvenlik sorumluları listesine yamanın önemini ve 30 gün sonraki açıklama takvimini bildirmeliydi
  • Bu açıklama güvenlikten çok pazarlama gibiydi
    Açıklama sayfasında da “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]” gibi ifadeler var
    Kargaşa büyüdükçe ürünü daha çekici gösteren bir yaklaşım bu
  • Bir kullanıcı ve yönetici olarak “son derece sorumsuzdu” değerlendirmesine katılmıyorum
    Responsible Disclosure ifadesi, “Secure Boot” gibi dilsel olarak iyi tasarlanmış bir ifade ve gerçekte bilgisayarımla benim arama giren şirketler ile vakıf benzeri aracı kurumların itibar yönetimine hizmet ediyor gibi görünüyor
    Onlar tek tek benim bilgisayarımın açık barındırmasından çok “RHEL açık içeriyor”, “Ubuntu açık içeriyor” denmesini engellemekle ilgileniyor
    Açık zaten var olduğuna göre, sessizce düzeltilmesini beklemektense riski bilip azaltma fırsatına sahip olmanın daha iyi olduğunu düşünüyorum
    Yani anında açıklamanın sorumsuz olmayan tek seçenek olduğunu düşünüyorum
  • Açıklama sürecinin kendisine dair pozisyon ne olursa olsun, bunun yüzünden hacklenen bir hosting provider zaten kaybetmeye mahkûm bir düzende çalışıyordu
    Birbirine güvenmeyen tenant workload’ları tek bir shared kernel altında çalıştırmak iyi bir fikir değil
    Kernel LPE nadir bir şey değil; bu olay sadece özellikle basit ve taşınabilir, ham capability’nin kendisi ise neredeyse sıradan bir CNE commodity düzeyinde
  • Linux kernel bir güvenlik sınırı olarak kullanılmaya uygun değil
    Shared hosting yapıp hacklenmemek istiyorsanız gVisor veya Firecracker VM gibi başka araçlar kullanmanız gerekir
    Bunu güvenlik sınırı olarak kullanan önemli sistemlerden biri Android; orada da APK kurulumunda kullanıcı onayı, sıkı SELinux ve seccomp politikaları, GrapheneOS hardening’i ile etki azaltılıyor
    Bu olayda da azaltım başarılı olmuş: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• “Linux kernel açığında, reporter bunu doğrudan linux-distros ML’ye götürmediği sürece dağıtımlar önceden bilgilendirilmiyor” denmesinin nedenini anlamıyorum
  Reporter’ın dağıtımlarla doğrudan koordinasyon kurması, Linux projesi hakkında yüksek düzeyde bilgi sahibi olmasını gerektiriyor
  Bir güvenlik açığını bildiren kişi, Linux kernel’in tüm downstream kullanıcılarıyla bizzat çalışmak zorunda olmamalı
  Bu mantıkla Linux kullanan tüm cihaz üreticilerine de tek tek haber vermek mi gerekiyor?
  Bence bildirimi yapan kişi Linux’a sorumlu şekilde bildirimde bulunup yama girene kadar bekleyerek zaten yeterince üzerine düşeni yaptı
  Linux projesi içinde güvenlik açıkları konusunda yetki ve sorumluluk sahibi kişiler olmalı ve downstream distro’ları bilgilendirme işini de onların yapması gerekir

  • Özellikle de reporter’a dağıtım ekiplerine önce haber vermemesi açıkça söylenirken bu daha da geçerli
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • Reporter’ın kendi sitesinde Ubuntu/RHEL/SUSE gibi belirli dağıtımları kontrol edip anacak kadar vakti vardı
    En azından bu dağıtımların güvenlik ekiplerine haber vermek sorumlu davranış olurdu gibi geliyor
  • Reporter Ubuntu, RedHat, Amazon ve SUSE’yi açıkça hedef gösteren bir site hazırlayıp da onları bilgilendirmediyse, bunun makul olduğunu söylemek zor
    Bu dağıtımların kernel ekibinin downstream’i olduğunu bilmediği de pek düşünülemez
  • Bu zorunlu bir gereklilik olmayabilir ama reporter’lar güvenli remediation yerine ün peşinde oldukları için herkes daha fazla sıkıntı yaşadı diye düşünüyorum
  • Linux distro’larına bu tür güvenlik sorunlarının nasıl bildirileceğini bulmak son derece kolay
    Google’da aratmak bile yeterli: https://share.google/aimode/eihDKXZJy94Z5lC1p
    Bunu hiç düşünmeden herkesi exploit’e açık bırakmayı anlamak zor; bazı yargı bölgelerinde bunun ağır suç sayılması da şaşırtıcı olmaz

• Disclosure ile ilgili en ilginç yazışma şu bağlantıda
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  greg k-h’nin cevabı şu yönde: “Kimseye önceden haber veremeyiz. Çünkü o zaman her şey için herkese haber vermemiz gerekir. Hukuk ve devlet kurumlarının çalışmamıza izin vermek için onayladığı tek politika bu, başka çaremiz yok.”

  • Linux’u seviyorum ama bunun aptalca bir politika olduğunu düşünüyorum

• Reporter’ı suçlamayı bırakıp kernel sürecinin düzeltilmesini talep etmek gerekiyor
  Linux kernel artık oyuncak bir proje değil ve çeşitli şirketlerde çalışan tam zamanlı çalışanlar var
  Dağıtımları bilgilendirme işini rastgele bir birey değil, onların yapması gerekirdi

  • Sunum amaçlı, fiilen pazarlama amaçlı bir blog yazısında belirli distro’ların etkilendiği isim verilerek yazıldıysa, açıklamadan önce bir heads-up verilmesi uygun ve beklenen davranış olurdu
    RHEL 14 gibi ifadeler oraya konmasaydı muhtemelen bu kadar tepki çekmezdi
    Burada durum, bireysel bir güvenlik araştırmacısı ya da akademi değil; profesyonel bir iletişim departmanına sahip bir güvenlik şirketinin distro maintainer’larını hedef alarak parmak sallaması
  • Dağıtımlar ile kernel geliştiricilerinin yüksek önem dereceli yamalar konusunda iletişim kurup hızlı hareket etmesi gerektiği doğru
    Ama reporter bunun olmasını beklemediği için gerçek insanlar zarar görmüş olabilir ve bunun sorumluluğu reporter’a ait
  • Güvenlik açığını bildirmek ile herkesin alıp kullanabileceği güçlü bir exploit yayımlamak tamamen farklı şeyler
    Büyük distro’lara önce haber vermeden bunu dünyaya salmak sorumsuzcaydı

• AF_ALG modül değil de kernel’e doğrudan bağlı derlenmiş kernel kullananlar için eBPF tabanlı bir workaround paylaşılmış: https://github.com/Dabbleam/CVE-2026-31431-mitigation
  Şu anda production’da çalıştırılıyor, saldırıyı azaltıyor ve şimdiye kadar beklenmedik bir yan etki görülmedi

• nosuid ve muhtemelen nodev varsayılan dosya sistemi mount option’ı olmalı diye düşünüyorum
  /dev zaten özel bir devtmpfs ve initrd’nin asgari /dev yapısı gerekiyorsa initrd tmpfs rootfs dev ve suid ile açıkça mount edilebilir
  SUID binary’lerin herhangi bir yerde “bulunabilmesine” izin vermek büyük bir güvenlik riski
  Harici depolama aygıtı mount edildiğinde o block device içindeki SUID binary’lerin kötü amaçlı olmadığını nasıl doğrulayabilirsiniz?
  Üstelik bu exploit’in çalışması için, SUID binary’yi çalıştıran kullanıcının o binary’yi okuyabilmesi de gerekiyor gibi görünüyor
  Root olmayan bir kullanıcının SUID binary üzerinde read iznine sahip olmasının bir nedeni yok
  NixOS bunu doğru ele alıyor
  Normal paket kurulum dizini olan /nix/store içinde SUID yok ve paketler bunun dışına sızmadığı için diğer mountpoint’lerde güvenle nosuid kullanılabiliyor
  Tek istisna, yalnızca executable-only SUID wrapper’ları güvenle barındıran tek amaçlı /run/wrappers.$hash dizini

  • Ben de suid’den hoşlanmıyorum ama burada asıl mesele suid değil
    Exploit edilen hata fiilen keyfî page cache poisoning yapılmasına izin veriyor
    O noktaya gelindiğinde oyun zaten bitmiş oluyor; suid programlarını patch’lemek root shell elde etmenin en kolay yolu olabilir ama tek yolu değil
  • Proof of concept exploit kelimenin tam anlamıyla sadece bir saldırı vektörünü göstermek için var
    Başka birçok yöntem bulunur
    Amaç sadece kavram kanıtı exploit’i engellemekse blacklist gibi daha kolay yöntemler de var; fakat bu sistemi daha güvenli yapmaz
    Bu açıkla page cache manipüle edilebiliyor
    ld.so manipüle edilerek keyfî system call’lara hook eklenebilir, uid 0 yapılabilir ya da başka birçok şekilde yetki yükseltilebilir
    Mount point’lerin bu konuyla ilgisi yok
    Elbette kullanıcı tarafından yazılabilir alanlarda suid’yi engellemek ve suid dosyalarının okunmasını engellemek her zaman iyi fikirdir, ama başka sebeplerden ötürü
    NixOS da bu açığı düzeltemiyor; diğer dağıtımlar gibi o da etkileniyor
  • Read izni yoksa binary çalıştırılamaz; bu mantıklı değil
    Bir binary’yi çalıştırmak için onu diskten okuyup belleğe yüklemek gerekir
    Hatta belirli bir binary için read izni var ama executable izni yoksa linker doğrudan çağrılarak yine çalıştırılabilir
    Örneğin /bin/ld.so.1 /path/to/binary şeklinde çağrılırsa linker binary’yi okuyup yükler ve exec() çağrısı yapmadan entry point’e atlar

• Aşağıdaki Bleeping Computer bağlantısında yama hazır olana kadarki olası önlemler yer alıyor
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • Bu workaround yalnızca etkilenen kodun modül olarak derlendiği kernel’lerde geçerli
    RHEL, Fedora ve Gentoo bu kodu doğrudan kernel içine derleyecek şekilde yapılandırılmış
    Yama ya da config değişikliği olmadan, Sam’in Gentoo için ima ettiği gibi bu dağıtımlar savunmasız kalmaya devam ediyor
  • RedHat ve türevlerinde etkilenen kod modül değil statik olarak derlenmiş durumda, bu yüzden bu önlem işe yaramıyor

• NixOS da önceden bilgilendirilmedi
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • Hiçbir dağıtım önceden bilgilendirilmedi

• Hyperbola GNU siyasi nedenler ve kararlılık gerekçesiyle hâlâ Python 3.8 kullandığı için güvendeydi

• Ubuntu yamayı yayımladı ve yama öncesi/sonrası testler de tamamlandı