Copy Fail – CVE-2026-31431

• Ayrıcalıksız yerel kullanıcı, authencesn, AF_ALG, splice() zincirini birleştirerek okunabilir bir dosyanın sayfa önbelleğine 4 bayt yazma primitive'i oluşturabiliyor ve bunun üzerinden root yetkisine kadar yükselebiliyor
• Çekirdeğe özgü offset'ler veya race condition olmadan, yalnızca 732 baytlık bir Python betiği ile birden çok Linux dağıtımında olduğu gibi çalışıyor ve aynı exploit ile root shell alınabiliyor
• Etki alanı, yama gelene kadar başlıca Linux dağıtımlarının büyük kısmını kapsıyor; varsayılan yapılandırmada etkin olan AF_ALG nedeniyle 2017'den yama anına kadar geniş ölçekte maruz kalınmış durumda
• Multi-tenant host'lar, Kubernetes / konteyner kümeleri, CI runner'ları ve kullanıcı kodu çalıştıran Cloud SaaS ortamlarında sıradan bir hesap ya da tek bir pod host root'una ulaşabildiği için öncelikli yama gerekiyor
• Müdahale için, mainline commit a664bf3d603d içeren çekirdek yaması öncelik taşıyor; yama öncesinde algif_aead devre dışı bırakılması ve güvenilmeyen iş yükleri için AF_ALG engellenmesi kritik önem taşıyor

---

Zafiyet özeti

• Doğrusal bir mantık hatası, authencesn, AF_ALG, splice() zinciriyle birleştirilerek sayfa önbelleğine 4 bayt yazma primitive'ine ve oradan da yerel ayrıcalık yükseltmeye dönüştürülebiliyor
• Çekirdeğe özgü offset'ler veya race window olmadan, tek bir 732 baytlık Python betiği ile 2017 sonrası yayımlanan Linux dağıtımlarının genelinde aynı şekilde çalışıyor
• Aynı exploit ikilisi, değişiklik olmadan birden çok dağıtımda root shell elde edebiliyor
• Yalnızca ayrıcalıksız bir yerel hesap yeterli; ağ erişimi, çekirdek hata ayıklama özellikleri veya önceden kurulu başka primitive'ler gerekmiyor

Etki alanı

• Yamadan önceki çekirdekleri kullanan başlıca Linux dağıtımlarının büyük bölümü kapsam içinde
• Çekirdek kriptografi API'sindeki AF_ALG, varsayılan yapılandırmada fiilen tüm ana akım dağıtımlarda etkin olduğu için 2017'den yama anına kadar doğrudan maruziyet söz konusu
• Doğrudan doğrulanan dağıtımlar Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 ve SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, Oracle ve gömülü sistem tarafı da etkilenen çekirdeği kullanıyorsa aynı şekilde etkileniyor

Öncelikli yama gerektiren ortamlar

• Multi-tenant Linux host'larda birden fazla kullanıcı aynı çekirdeği paylaştığı için herhangi bir kullanıcı hesabı doğrudan root olabilir
• Kubernetes / konteyner kümelerinde sayfa önbelleği host genelinde paylaşıldığından tek bir pod node'u ele geçirip tenant sınırlarını aşabilir
• CI runner'ları ve build farm'larda normal kullanıcı yetkisiyle çalışan güvenilmeyen PR kodu runner üzerinde root olabilir
• Kullanıcı kodu çalıştıran Cloud SaaS ortamlarında tenant'ın yüklediği konteyner ya da betik host root'una gidebilir
• Tek tenant'lı sunucular daha çok dahili LPE niteliği taşır ve web RCE veya ele geçirilmiş kimlik bilgileriyle birleşebilir
• Tek kullanıcılı dizüstü ve workstation'larda aciliyet daha düşüktür, ancak yerel kod çalıştırma doğrudan root yükseltmesine dönüşebilir

Yayınlanan PoC ve kullanım şekli

• PoC, savunma ekiplerinin sistem doğrulaması ve üretici yama kontrolü yapabilmesi için yayınlanmış durumda
• copy_fail_exp.py, Python 3.10+ standart kütüphanesinden yalnızca os, socket, zlib kullanıyor
• Varsayılan hedef /usr/bin/su ve argv[1] ile başka bir setuid ikilisi verilebiliyor
• Sayfa önbelleğindeki setuid ikilisini değiştiriyor; değişiklik yeniden başlatma sonrası kalıcı olmuyor ama elde edilen root shell fiilen çalışıyor
• Issue tracker

Hafifletme yöntemleri

• İlk olarak çekirdek yaması gerekiyor ve mainline commit a664bf3d603d içeren dağıtım çekirdeğine güncellenmeli
• Bu yama, 2017'de eklenen algif_aead içi in-place optimizasyonunu geri alarak sayfa önbelleği sayfalarının yazılabilir hedef scatterlist'e girmesini engelliyor
• Yama öncesinde algif_aead modülünün devre dışı bırakılması öneriliyor
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
• Güvenilmeyen iş yükleri çalıştıran konteyner, sandbox ve CI ortamlarında, yama durumundan bağımsız olarak seccomp ile AF_ALG socket oluşturmanın engellenmesi gerekiyor

Devre dışı bırakmanın etkisi

• Çoğu sistemde ölçülebilir etki neredeyse yok
• dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS varsayılan derlemeleri, SSH ve kernel keyring crypto etkilenmiyor
  • Bunlar çekirdek kriptografi API'sini doğrudan kullanıyor ve AF_ALG yolundan geçmiyor
• OpenSSL'de afalg engine açıkça etkinleştirildiyse, bazı gömülü kripto offload yolları ve aead/skcipher/hash socket'lerini doğrudan bind eden uygulamalar etkilenebilir
  • lsof | grep AF_ALG veya ss -xa ile kontrol edilebilir
• AF_ALG kapatılsa da zaten onu çağırmayan hedeflerde yavaşlama olmaz; kullananlar ise normal userspace kriptografi kütüphanelerine geri döner

Tipik Linux LPE'lerinden farkı

• Tipik Linux LPE'lerinden farklı olarak race condition yok ve dağıtıma özgü offset'ler gerekmiyor
• Güvenilirlik de tek denemede %100 olarak sunuluyor ve dar bir çekirdek sürümü aralığı yerine 2017'den 2026'ya kadar uzun bir dönemi kapsıyor
• Yalnızca Python standart kütüphanesi kullanan 732 baytlık bir betik olduğundan derlenmiş payload veya ek bağımlılık gerekmiyor
• Yazma yolu VFS'yi atlıyor ve bozulmuş sayfa dirty olarak işaretlenmediği için diske hiçbir şey yazılmıyor
• Sayfa önbelleği host genelinde paylaşıldığından, basit bir LPE'nin ötesinde konteyner kaçışı primitive'i olarak da çalışıyor

Çalışma mantığı ve tespit özellikleri

• Ayrıcalıksız yerel kullanıcı, Linux sistemde okunabilir dosya sayfa önbelleğine kontrol edilebilir 4 bayt yazabiliyor ve bunu root elde etmek için kullanabiliyor
• Hedef, diskteki gerçek dosya değil bellek içindeki sayfa önbelleği; /usr/bin/su için önbellek kopyası değiştirilirse execve açısından ikilinin kendisi değiştirilmiş gibi oluyor
• Diskte değişiklik olmadığından inotify tetiklenmiyor; yeniden başlatma veya önbellek tahliyesi sonrasında özgün dosya yeniden yükleniyor
• sha256sum, AIDE, Tripwire gibi genel hash araçları read() üzerinden sayfa önbelleğini okuduğu için önbellekte bozulma kaldığı sürece referans hash'ten farklı sonuç verebilir
• Önbellek tahliye edilince veya sistem yeniden başlatılınca hash yeniden özgün değerle eşleşir ve disk adli kopyasında da yalnızca değiştirilmemiş dosya kalır
• IMA appraisal enforcing mode altında every-read measurement açıksa, bozulmuş ikili çalıştırılmadan önce execve anında yakalanabilir

Diğer zafiyetlerden farkı

• Dirty Pipe ile aynı ailede; ayrıcalıksız userspace'ten sayfa önbelleğini bozup, diskte değişiklik yapmadan setuid ikilisine yazarak root elde edilmesi bakımından benzer
• Mekanizma farklı: Dirty Pipe pipe buffer flags'i kötüye kullanırken, Copy Fail zincirli scatterlist sınırını aşan AEAD scratch write'ı kötüye kullanıyor
• Dirty Pipe, belirli yamaları almış çekirdek 5.8+ gerektiriyordu; Copy Fail ise 2017'den 2026'ya uzanan pencereyi kapsıyor
• Dirty Cow'dan farklı olarak TOCTOU tabanlı COW race'ini kazanmak gerekmiyor, çok sayıda deneme yapılmıyor ve sistem kararsızlaştırılmıyor

Ek ayrıntılar

• /usr/bin/su zorunlu değil; kullanıcının okuyabildiği bir setuid-root ikilisi ise passwd, chsh, chfn, mount, sudo, pkexec de hedef olabilir
• Uzak bir zafiyet değil; önce normal kullanıcı yetkileriyle yerel kod çalıştırma gerekiyor
• Web RCE ayrıcalıksız bir servis hesabına düşüyorsa, SSH foothold veya CI runner'daki kötü niyetli PR gibi yollarla birleştiğinde root'a çıkılabilir
• Yama, algif_aead içindeki in-place optimizasyonu geri alıp req->src ile req->dst'yi yeniden ayrık scatterlist'lere dönüştürüyor
• Sayfa önbelleği sayfaları yalnızca salt okunur kaynakta kalıyor ve kriptografinin yazabildiği hedef olarak sadece kullanıcı buffer'ı kalıyor

Açıklama takvimi ve devam materyalleri

• 2026-03-23 tarihinde Linux çekirdek güvenlik ekibine bildirildi
• 2026-03-24 tarihinde ilk doğrulama yapıldı
• 2026-03-25 tarihinde yama önerildi ve incelendi
• 2026-04-01 tarihinde yama mainline'a commit edildi
• 2026-04-22 tarihinde CVE-2026-31431 atandı
• 2026-04-29 tarihinde https://copy.fail/ üzerinde kamuya açıklandı
• Xint blog teknik analizi
  • root cause, scatterlist diyagramları, 2011→2015→2017 zaman çizelgesi ve exploit walkthrough içeriyor
  • Kubernetes konteyner kaçışını ele alan Part 2'nin daha sonra yayımlanması planlanıyor

Xint Code ile ilgili bilgiler

• AI-assisted bir yaklaşımla bulundu; çıkış noktası, splice()'ın sayfa önbelleği sayfalarını crypto subsystem'e aktarabilmesi ve scatterlist'teki sayfa kökeninin daha az araştırılmış bir hata sınıfı olabileceğine dair insan araştırmasıydı
• Sonrasında Xint Code, Linux crypto/ subsystem'in tamamına yönelik denetimi yaklaşık 1 saatlik ölçeğe genişletti ve sonuçlar içindeki en kritik bulgu Copy Fail oldu
• Xint Code
  • Xint blog write-up
  • Aynı taramada başka yüksek riskli hatalar da bulundu; bunlar için coordinated disclosure süreci hâlâ devam ediyor