Copy Fail CVE-2026-31431: Linux Kernel Yerel Yetki Yükseltme Zafiyeti

30 Nisan 2026'da CERT-EU, Linux kernel tarafında yüksek öncelikli bir yerel yetki yükseltme zafiyeti için Security Advisory 2026-005'i yayımladı. Zafiyet CVE-2026-31431 olarak takip ediliyor ve araştırmacılar tarafından Copy Fail adıyla duyuruldu.

Kısa özet: Bu açık, unprivileged local user seviyesindeki bir kullanıcının belirli koşullarda kernel crypto API yüzeyi üzerinden page cache üzerinde kontrollü yazma yapmasına ve setuid binary hedefleyerek root shell elde etmesine yol açabilir. Bu yüzden risk "uzaktan herkes root olur" gibi okunmamalı; fakat Kubernetes node, shared runner, build farm, notebook platformu ve kullanıcı kodu çalıştıran SaaS ortamlarında hızla kritik hale gelir.

Etkilenen alan

CERT-EU advisory'sine göre sorun, 2017'den itibaren build edilmiş kernel'ları etkileyen algif_aead modülü ve kernel userspace crypto API yüzeyiyle ilişkili. Araştırmacılar Ubuntu, Amazon Linux, RHEL ve SUSE üzerinde doğrulama yaptıklarını belirtiyor. Aynı kernel aralığında çalışan Debian, Arch, Fedora, Rocky Linux, AlmaLinux, Oracle Linux ve gömülü Linux dağıtımları da risk değerlendirmesine dahil edilmeli.

Önceliklendirme açısından en kritik sistemler:

• Kubernetes node'ları ve container host'ları.
• Self-hosted GitHub Actions, GitLab Runner, Jenkins agent ve benzeri CI/CD runner'ları.
• Çok kullanıcılı Linux sunucular.
• Müşteri veya tenant kodu çalıştıran notebook, sandbox ve SaaS altyapıları.
• Build farm ve paketleme sistemleri.

Tek kiracılı, sadece güvenilir ekibin shell erişimi olan sunucularda risk daha düşük görünür; ancak bir web RCE, çalınmış SSH anahtarı veya compromised deploy key ile zincirlendiğinde yerel yetki yükseltme etkisi yine kritiktir.

Teknik risk: algif_aead, AF_ALG ve splice()

Zafiyet algif_aead modülündeki bir optimizasyon davranışından kaynaklanıyor. CERT-EU açıklamasına göre, 2017'de gelen bir in-place optimization page-cache sayfalarının writable destination scatterlist içine girmesine yol açabiliyor. Saldırgan, AF_ALG socket operasyonunu splice() ile zincirleyerek page-cache-backed bir sayfaya kontrollü kısa yazma yapabiliyor.

Bu teknik detay önemli çünkü exploit zinciri klasik yarış koşuluna veya kernel offset bilgisine yaslanmıyor. Yerel kullanıcı hesabı olan saldırgan için daha deterministik bir pratik risk doğuyor. Araştırmacıların yayımladığı PoC nedeniyle savunma tarafında beklemek yerine geçici önlem uygulamak daha doğru.

Neden Kubernetes ve CI/CD runner öncelikli?

Container güvenliği çoğu zaman "container root host root değildir" cümlesiyle anlatılır. Ancak container aynı kernel'ı paylaşır. Kernel yerel yetki yükseltme açığında tenant izolasyonu, container boundary ve runner izolasyonu beklenenden hızlı çöker.

Özellikle şu senaryolar risklidir:

• Untrusted pull request kodu self-hosted runner üzerinde çalışıyor.
• Kullanıcı notebook'u veya job script'i aynı host kernel'ını paylaşıyor.
• Build container'ları privileged veya geniş seccomp profiliyle koşuyor.
• Multi-tenant Kubernetes ortamında workload'lar aynı node üzerinde yoğunlaşıyor.

Bu ortamlarda patch penceresi beklenirken AF_ALG socket creation engeli, riskin sömürülebilirliğini ciddi biçimde düşürür.

Hızlı envanter komutları

Aşağıdaki komutlar etki analizi için başlangıç sağlar. Bunlar tek başına kesin güvenlik kararı değildir; dağıtım vendor advisory'si ve kernel build bilgisiyle birlikte değerlendirilmelidir.

uname -a
uname -r
lsmod | grep algif_aead || true
lsof | grep AF_ALG || true
ss -xa | grep -i alg || true

Container host'ları için ayrıca seccomp profilini ve workload güvenlik bağlamlarını kontrol edin:

kubectl get pods -A -o wide
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.seccompProfile.type}{"\n"}{end}'

Geçici önlem

Vendor kernel patch'i hazır olana kadar CERT-EU'nun önerdiği pratik geçici önlem algif_aead modülünü devre dışı bırakmaktır:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Bu değişiklikten sonra ilgili host'larda özel olarak AF_ALG kullanan uygulama olup olmadığı kontrol edilmelidir:

lsof | grep AF_ALG || true
ss -xa | grep -i alg || true

CERT-EU, bu workaround'un dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS veya SSH gibi yaygın kullanımları genelde etkilemediğini; ancak özellikle afalg engine veya doğrudan aead/skcipher/hash socket kullanan uygulamaların incelenmesi gerektiğini belirtiyor.

Container ve pipeline hardening

Untrusted workload çalıştıran sistemlerde yalnızca kernel modülünü devre dışı bırakmakla yetinmeyin. AF_ALG socket creation seccomp ile engellenmelidir. Bu kontrol patch sonrası da savunma katmanı olarak kalabilir.

Docker/Podman ve Kubernetes tarafında amaç şudur:

• Container içinden AF_ALG socket açılmasını engellemek.
• Privileged container sayısını azaltmak.
• HostPath mount ve geniş Linux capability kullanımını review etmek.
• Build runner'ları ephemeral ve izole node havuzlarında çalıştırmak.
• Untrusted PR job'larını production credential'larından ayırmak.

Patch stratejisi

Geçici önlem patch'in yerine geçmez. Dağıtımınız kernel paketini yayımladığında:

1. Vendor advisory'sini doğrulayın.
2. Kernel paketini test ortamında kurun.
3. Reboot gereksinimini planlayın.
4. CI runner ve Kubernetes node havuzlarını dalga dalga güncelleyin.
5. Patch sonrası algif_aead devre dışı bırakma kararını uygulama bağımlılığına göre yeniden değerlendirin.
6. Seccomp kısıtını untrusted workload sınıflarında kalıcı hale getirin.

Eresus bakış açısı

Copy Fail, modern altyapı güvenliğinde "yerel açık" kategorisinin neden hafife alınmaması gerektiğini gösteriyor. Yerel yetki yükseltme zafiyeti tek başına internetten sömürülebilir olmayabilir; fakat CI/CD, container ve SaaS sandbox mimarilerinde saldırgan zaten kontrollü biçimde kod çalıştırma fırsatı bulabilir.

Eresus Security bu tür olaylarda sadece CVE listesini takip etmez. Kritik soru şudur:

• Hangi host'lar untrusted workload çalıştırıyor?
• Hangi runner'lar production secret'larına erişiyor?
• Hangi Kubernetes node havuzlarında tenant karışımı var?
• Hangi sistemlerde patch penceresi operasyonel olarak gecikecek?
• Hangi geçici önlem gözlemlenebilir ve geri alınabilir şekilde uygulanabilir?

Bu sorulara cevap yoksa "patch bekliyoruz" demek risk yönetimi değildir.

SSS

Bu uzaktan sömürülebilen bir açık mı?

Hayır, açıklanan senaryo yerel yetki yükseltme sınıfındadır. Ancak web RCE, compromised SSH, CI job, notebook veya tenant-supplied container ile zincirlenirse etkisi root yetkisine kadar büyüyebilir.

Tüm Linux sistemleri aynı öncelikte mi?

Hayır. Çok kiracılı host, Kubernetes node, build runner ve kullanıcı kodu çalıştıran sistemler en üst önceliktedir. Tek kiracılı ve sadece güvenilir kullanıcıların eriştiği sunucular yine patchlenmeli ama operasyon sıralamasında farklı ele alınabilir.

Seccomp patch yerine geçer mi?

Hayır. Seccomp, özellikle container ve pipeline ortamlarında exploit başlangıcını engellemek için güçlü bir geçici ve kalıcı savunma katmanıdır. Kalıcı çözüm vendor kernel patch'idir.

Hemen ne yapmalıyız?

Önce envanteri çıkarın, algif_aead kullanımını kontrol edin, untrusted workload çalıştıran host'larda geçici önlemi uygulayın, vendor patch takibini açın ve patch penceresini planlayın.

Kontrol listesi

• Kernel sürümü ve dağıtım advisory'si kontrol edildi mi?
• algif_aead modülü yüklü mü?
• Host üzerinde AF_ALG kullanan uygulama var mı?
• Kubernetes node ve CI runner listesi çıkarıldı mı?
• Untrusted workload sınıfları ayrıldı mı?
• Seccomp ile AF_ALG socket creation engellendi mi?
• Vendor patch takibi ve reboot planı açıldı mı?
• Patch sonrası doğrulama komutları runbook'a eklendi mi?