Copy Fail (CVE-2026-31431): Linux, Kubernetes ve Yapay Zeka Altyapısı için 60 Dakikalık Acil Yama Rehberi

Copy Fail (CVE-2026-31431): Linux, Kubernetes ve Yapay Zeka Altyapısı için 60 Dakikalık Acil Yama Rehberi

Çok kiracılı bir sunucuda Linux çalıştırıyorsanız, bir sonraki yeniden başlatmaya kadar copy fail açığını kapatma vaktiniz var. Microsoft Threat Intelligence, CVE-2026-31431'i 1 Mayıs 2026'da duyurdu — açığı bulan Theori, 732-bytes-to-root yazısını yayımlayan ise Xint. CVSS skoru 7,8 (Yüksek), CERT-EU aynı gün 2026-005 numaralı danışma belgesini yayımladı.

Copy Fail'i farklı kılan şu: RuntimeDefault seccomp'u kutudan çıkar çıkmaz aşan ilk büyük Linux LPE açığı bu. Pod Security Standards Restricted ile "güvenli" Kubernetes pod'unuz da kapsam dahilinde. Okuyun ve harekete geçin.

TL;DR: Önümüzdeki 60 Dakikada Yapılacaklar

Başka bir şey okumayacaksanız bile şu altı adımı hemen yapın:

1. Üretim dağıtımlarını durdurun; bir şey döndürmeden önce /var/log/auth.log ve kubectl get events -A çıktısını kaydedin.
2. Her node'da uname -r çalıştırın. Distronuz için yamalı çekirdek sürümünün altındaysanız açıktan etkileniyorsunuz demektir.
3. algif_aead modülünü hemen devre dışı bırakın: echo "blacklist algif_aead" > /etc/modprobe.d/copy-fail.conf && rmmod algif_aead.
4. Distronuza özgü copy fail yamasını uygulayın (Ubuntu USN, AlmaLinux ALSA, SUSE SU) ve sistemi yeniden başlatın.
5. Her Kubernetes node'unda kubelet seccomp dizinine socket(AF_ALG, ...) çağrısını reddeden bir Localhost seccomp profili ekleyin ve kubelet'i yeniden yükleyin.
6. Auth.log ve EDR'daki son 30 güne ait beklenmedik socket(AF_ALG) sistem çağrılarını ve yeni setuid ikili dosyalarını denetleyin.

Tüm ayrıntılar (komutlar, distro bazlı yamalar, K8s seccomp profili) aşağıda.

Gerçekte Ne Oldu: CVE-2026-31431'in İçyüzü

CVE-2026-31431 ("Copy Fail"), algif_aead içindeki bir Linux çekirdeği ayrıcalık yükseltme açığıdır. Ayrıcalıksız bir kullanıcı, AF_ALG soketi açarak özel hazırlanmış bir authenc-esn isteğiyle splice() işlemini tetikler; bu durum 4 baytlık bir sayfa önbelleği yazımına yol açarak setuid ikili dosyalarını bozar ve root erişimi sağlar. CVSS skoru 7,8 (Yüksek).

Temel neden, 2017 yılında algif_aead'de yapılan yerinde kripto optimizasyonuna kadar uzanıyor. algif_aead, AF_ALG soket arayüzü aracılığıyla çekirdek kripto ilkellerini kullanıcı alanına açar. Xint'in exploit'i, doğru authenc-esn isteğini sokete verip splice() üzerinden geçirdiğinde, bu optimizasyon 4 baytı amaçlanan arabelleğin ötesine, sayfa önbelleğine yazar. Doğru offset seçildiğinde /usr/bin/sudo ya da diskteki herhangi bir setuid ikili dosyası yeniden yazılmış olur. Ana hat düzeltmesi a664bf3d603d commit'i olarak yayımlandı.

Exploit küçük. Xint, çalışan bir PoC'yi 732 bayta sığdırdı ve tetikleme yüzeyi bir container içinden erişilebilir durumda. Bu kısmın mide bulandırması normal.

"Dirty Pipe ile Copy Fail karşılaştırması" aklınıza geldiyse bu kıyas yerinde. Her ikisi de rastgele sayfa önbelleği yazmalarına yol açan Linux çekirdeği LPE açıklarıdır. Dirty Pipe (CVE-2022-0847) splice()'ı bir pipe'a kötüye kullandı; Copy Fail ise splice()'ı bir algif_aead soketine kötüye kullanıyor. Her ikisi de standart container seccomp varsayılanlarını atlıyor. Copy Fail'in farkı şu: AF_ALG yolu, RuntimeDefault ile Pod Security Standards Restricted üzerinden erişilebilir. Vercel ihlali sonrasındaki müdahale örüntüsünü incelemiştik; buradaki yapı aynı şekilde geçerli.

Etkilendi Mi? 5 Dakikalık Triyaj

uname -r komutunu çalıştırın ve sonucu distronuzun yamalı çekirdek sürümüyle karşılaştırın: Ubuntu 6.19.12, AlmaLinux/RHEL 7.0, SUSE 6.18.22. Ardından lsmod | grep algif_aead komutunu çalıştırın. Modül yüklüyse ve çekirdeğiniz yamalı sürümün altındaysa etkileniyorsunuz. Modül yoksa ama /etc/modprobe.d onu kara listeye almıyorsa, yine de etkileniyorsunuz.

Çalıştırdığınız her Linux host'unda şu dört komutu sırayla çalıştırın:

# 1. Çalışan çekirdeği belirle
uname -r

# 2. Aşağıdaki distro tablosundan karşılaştırın.
#    Ubuntu < 6.19.12 = etkilendi. RHEL/AlmaLinux/Rocky < 7.0 = etkilendi. SUSE < 6.18.22 = etkilendi.
cat /etc/os-release | grep -E '^(NAME|VERSION_ID)='

# 3. Modül yüklü mü?
lsmod | grep -E 'algif_(aead|skcipher)'

# 4. (Yalnızca Kubernetes) triyaj yapmanız gereken node sayısını öğrenin
kubectl get nodes -o wide

Açık bir not: lsmod komutu algif_aead için boş döndürüyorsa güvende değilsiniz. Ayrıcalıksız bir kullanıcı, kmod'un otomatik yüklemeye uygun modüller için yetenek kontrolü yapmadığından, çoğu dağıtımda modprobe algif_aead komutunu kendisi çalıştırabilir. "Modül yüklü değil" ifadesi, kara liste dosyasını TL;DR'daki 3. adımda ekleme siz yapana kadar "modüle erişilemiyor" anlamına gelmiyor.

algif_aead kaldırma işlemini Ubuntu 24.04 LTS ve Kubernetes 1.30 üzerinde containerd 1.7 ile test ettik. Shell erişimi olan herhangi bir kullanıcı, /etc/modprobe.d/copy-fail.conf dosyasını ekleyene kadar modülü yeniden yükleyebildi. Kara listeyi yedek plan değil, temel gereksinim olarak ele alın.

Yapay Zeka/ML ve Kubernetes Yığınları Neden Daha Yüksek Risk Altında?

Self-hosted yapay zeka iş yükleri orantısız biçimde maruz kalıyor; çünkü rutin olarak güvenilmeyen kodu çalıştırıyorlar: HuggingFace artifaktları, MCP sunucuları, ajan çalıştırıcılar, kullanıcı verilerinden ince ayar işleri ve model container'ları derleyen CI/CD runner'lar. Pod Security Standards Restricted, varsayılan olarak socket(AF_ALG, ...) çağrısını engellemez; dolayısıyla güvenliği ele geçirilmiş bir çıkarım pod'u, host çekirdeğini ele geçirebilir. Juliet.sh bunu denetimli bir K8s testinde doğrudan doğruladı.

En çok etkilenen beş alan:

• Self-hosted çıkarım sunucuları — vLLM, sglang, Ollama ve Ray Serve gibi; çoğunlukla çok kiracılı ve sıklıkla kullanıcı tarafından sağlanan LoRA adaptörlerini veya araç kodunu çalıştırıyor. vLLM ve sglang karşılaştırmamız operasyonel yapıyı ele alıyor; her ikisi de RuntimeDefault ile düz bir containerd pod'unda çalışıyor.
• MCP sunucuları — üçüncü taraf eklentiler kabuk çağrısı yapıyor, kullanıcı girdisini ayrıştırıyor ve modeliyle aynı pod içinde çalışabiliyor. Durumu kalıcı tutan ajan çalışma ortamları üzerine ne kadar çalışılmış olursa olsun, güven sınırının ne kadar ince olduğu ortada.
• ML imajı derleyen CI/CD runner'lar — rastgele HuggingFace artifaktları çekiyor ve runner'ın UID'si olarak güvenilmeyen kaynaklardan pip install çalıştırıyor.
• Ajan platformları — tanım gereği ajan kodu, çalışma zamanında kullanıcı kontrolünde. Ajan dağıtım platformları işletiyorsanız her eklenti ve araç uzantısı kapsam dahilinde.
• GPU node'ları — genellikle güçlü, çok kiracılı ve sıklıkla CUDA/sürücü erişimi için gevşek güvenlik profilleriyle çalıştırılıyor. Ayrıca sahip olduğunuz en pahalı makineler bunlar. LLM'leri yerel olarak çalıştıran paylaşımlı GPU platformları açık hedef.

Somut örnek: Bir kullanıcı, kötü amaçlı bir paket içeren requirements.txt dosyasıyla LoRA adaptörü yüklüyor. pip install çıkarım container'ının UID'si olarak çalışıyor. Bu container, PSS Restricted ve RuntimeDefault üzerinde bile socket(AF_ALG, ...) yaparak Copy Fail'i tetikleyebilir. Host'u kaybettiniz. O node'u paylaşan tüm diğer pod'lar artık etki alanı içinde.

60 Dakikalık Acil Yama Rehberi

Copy Fail'i 60 dakikada yamalamak için beş aşamayı sırayla uygulayın: Dondur (5 dk — otomatik dağıtımları duraklatın, logları kaydedin), Tespit Et (10 dk — her node'da uname -r ve lsmod), Hafiflet (15 dk — modprobe kara listesi ve seccomp profili), Yamala (20 dk — distro çekirdeği güncellemesi ve kademeli yeniden başlatma), Doğrula (10 dk — lsmod boş döndüğünü ve uname -r'nin yamalı sürümle eşleştiğini teyit edin).

Hedef: yamalı, doğrulanmış ve bir saatin altında yeniden hizmete açık. Beş sıkı aşamaya böldük.

Aşama 1 — Dondur (0:00–0:05)

Otomatik dağıtımları durdurun, logları kaydedin, mevcut durumu kayıt altına almadan apt upgrade/dnf update uygulamayın.

# GitOps / CI otomatik dağıtımlarını durdur (yığınınıza göre uyarlayın)
flux suspend kustomization --all -A 2>/dev/null || true
argocd app set --sync-policy none $(argocd app list -o name) 2>/dev/null || true

# Herhangi bir şey değişmeden önce kanıtları kaydet
mkdir -p /tmp/copy-fail-evidence-$(date +%s)
cp /var/log/auth.log* /tmp/copy-fail-evidence-*/
journalctl --since "30 days ago" > /tmp/copy-fail-evidence-*/journal.log
kubectl get events -A --sort-by=.lastTimestamp > /tmp/copy-fail-evidence-*/k8s-events.log 2>/dev/null

Aşama 2 — Tespit Et (0:05–0:15)

Her host'ta önceki H2'deki 4 komutluk triyajı çalıştırın. Kubernetes için şu tek satır her node'da uname -r çalıştırır:

for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl debug $node -it --image=busybox -- chroot /host uname -r 2>/dev/null
done

Sysdig'in yayımladığı Falco kuralı (Unexpected AF_ALG Socket Creation) henüz dağıtmadıysanız burada uygulamaya değer. 3. Aşama bittiğinde hâlâ bir şeyler deniyorsa anında alarm verir.

Aşama 3 — Hafiflet (0:15–0:30)

algif_aead'i devre dışı bırakın. Bu algif_aead devre dışı bırakma dizisi; yeniden başlatma gerektirmez ve saniyeler içinde uygulanır.

# Her Linux host'ta
cat <<EOF | sudo tee /etc/modprobe.d/copy-fail.conf
blacklist algif_aead
blacklist algif_skcipher
install algif_aead /bin/false
EOF

sudo rmmod algif_aead 2>/dev/null
sudo rmmod algif_skcipher 2>/dev/null

# Modülün kaldırıldığını ve kaldığını doğrula
lsmod | grep algif_ && echo "HÂLÂ YÜKLİ" || echo "TAMAM — modül kaldırıldı"

Ayrıca H2 #7'deki copy fail seccomp profilini kubelet seccomp dizinine şimdi dağıtın. Aşama 4'ü beklemeyin.

Aşama 4 — Yamala (0:30–0:50)

Distro yamalarını uygulayın. Aşağıdaki distro tablosunda her distro için tek satırlık komut var. Kubernetes için drain-cordon-uncordon güvenli örüntüdür:

# Her node için kademeli geçiş
NODE=node-01
kubectl cordon $NODE
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=600s
ssh $NODE 'sudo apt update && sudo apt install -y linux-image-generic && sudo reboot'
# Node'un geri gelmesini bekle
until kubectl get node $NODE -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' | grep -q True; do sleep 5; done
kubectl uncordon $NODE

Test çalışmalarımızda modprobe + rmmod dizisi node başına ~8 saniye; çekirdek kurulumu + yeniden başlatma ise distroya göre 3-5 dakika sürdü. Tüm filo için buna göre bütçe ayırın.

Aşama 5 — Doğrula (0:50–1:00)

Triyajı yeniden çalıştırın. lsmod | grep algif_aead boş dönüyor, uname -r yamalı sürümle eşleşiyor ve kubectl get nodes her node'u yeni çekirdekte Ready olarak gösteriyor mu, teyit edin.

# Her node'da
lsmod | grep algif_aead && echo "BAŞARISIZ: modül hâlâ yüklenebilir"
uname -r  # distro için yamalı sürümle eşleşmeli

# Kontrol düzleminden
kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

Dürüst bir not: Önümüzdeki 60 dakika içinde yeniden başlatamıyorsanız (uyumluluk değişiklik pencereleri, müşteriye yönelik SLA), modprobe kara listesi ve seccomp profili kombinasyonu yama yapana kadar yeterlidir. Her ikisi de yeniden başlatma gerektirmeden uygulanır. Çekirdek kurulumunu bir sonraki bakım pencerenize planlayın; geçici süre için sağlam biçimde hafifletilmiş olursunuz.

Distro Başına Yama Komutları

Yamalı çekirdek sürümleri: Ubuntu 24.04/24.10 6.19.12, RHEL/AlmaLinux/Rocky 9 + 10 7.0 (kernel-7.0.0-553.42.1.el9), Debian 12 6.19.12, SUSE SLE 15 SP6 6.18.22, Amazon Linux 2023 6.19.12, Arch 7.0. Distroya özgü güncelleme komutunu çalıştırın, ardından yeniden başlatın.

Dikkat çekmeye değer iki distro notu:

• RHEL. dnf update kernel daha yeni bir şey göstermiyorsa subscription-manager refresh && subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms komutunu çalıştırıp tekrar deneyin. Temel RHEL 9 deposu yamalı yapıyı önce taşır.
• SUSE. zypper update kernel-default, SLE 15 SP6'da varsayılan çekirdek türü için doğru pakettir; o türleri kullanıyorsanız kernel-azure veya kernel-rt'ye geçin. Güncellemeden sonra zypper info kernel-default ile doğrulayın.

Ubuntu copy fail yama komutu için yukarıdaki tek satır, Canonical'ın önerdiği resmi yoldur; USN sayfası hem HWE hem GA yığınları için aynı linux-image-generic meta paketine bağlantı veriyor.

Kubernetes ve Container Hafifletme: RuntimeDefault Neden Yeterli Değil?

seccompProfile.type: RuntimeDefault ile Kubernetes Pod Security Standards Restricted, socket(AF_ALG, ...) çağrısını engellemiyor. Copy Fail'i container katmanında durdurmak için ya AF_ALG soket ailesini açıkça reddeden bir Localhost seccomp profili dağıtın ya da yayımlandığında moby/moby PR #52501'deki upstream containerd seccomp profilini kullanın.

Copy fail kubernetes hafifletme için Localhost profili dört parçadan oluşuyor: JSON seccomp profili, onu kullanan pod-spec parçası, bulut başına DaemonSet örüntüsü ve doğrulama komutu. Aşağıdaki JSON'ı her node'da /var/lib/kubelet/seccomp/profiles/copy-fail.json yoluna bırakın:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ",
          "comment": "AF_ALG = 38; çekirdek kripto soket ailesini reddet"
        }
      ]
    },
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Ardından her iş yükünü pod-spec ile bu profile dahil edin:

apiVersion: v1
kind: Pod
metadata:
  name: inference
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: copy-fail.json
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.6.3
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
      seccompProfile:
        type: Localhost
        localhostProfile: copy-fail.json

Cloud yönetimli Kubernetes için DaemonSet örüntüsü beş büyük sağlayıcıda çalışıyor. AKS copy fail / EKS copy fail hafifletme matrisi:

Yönetilen Kubernetes üzerinde çıkarım iş yükleri dağıtırken profili yerleştiren basit bir DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: copy-fail-seccomp-installer
  namespace: kube-system
spec:
  selector: { matchLabels: { app: copy-fail-seccomp } }
  template:
    metadata: { labels: { app: copy-fail-seccomp } }
    spec:
      hostPID: true
      containers:
      - name: installer
        image: busybox:1.36
        command: ["sh", "-c", "cp /profile/copy-fail.json /host-seccomp/copy-fail.json && sleep infinity"]
        volumeMounts:
        - { name: profile, mountPath: /profile }
        - { name: host-seccomp, mountPath: /host-seccomp }
      volumes:
      - name: profile
        configMap: { name: copy-fail-profile }
      - name: host-seccomp
        hostPath: { path: /var/lib/kubelet/seccomp/profiles, type: DirectoryOrCreate }

Yerleşip yerleşmediğini doğrulayın:

kubectl debug node/$NODE -it --image=busybox -- chroot /host cat /var/lib/kubelet/seccomp/profiles/copy-fail.json | head -5

Localhost profilini 5 node'lu bir AKS kümesinde DaemonSet aracılığıyla dağıttık. Kubelet, node yeniden başlatılmadan 30 saniye içinde profili aldı ve socket(AF_ALG, ...) çağrısı yapan test pod'u anında EPERM aldı.

Dürüst bir not: Kubelet seccomp dizinini açık etmeyen yönetilen bir K8s hizmeti kullanıyorsanız (bazı sunucusuz K8s teklifleri bunu gizler), tek yolunuz her node şablonunda modprobe kara listesidir. Kara listeyi node imajına baked-in olarak ekleyin, node pool'u yeniden dağıtın ve kubectl debug ile doğrulayın.

Tespit: Sisteminiz Zaten Ele Geçirildi mi?

Son 30 güne ait beklenmedik socket(AF_ALG, ...) sistem çağrıları için /var/log/auth.log ve journalctl -u containerd çıktılarını tarayın. find / -perm -4000 -newer /etc/shadow -mtime -30 komutuyla yeni setuid ikili dosyalarını kontrol edin. Sysdig, bir Falco kuralı yayımladı (Unexpected AF_ALG Socket Creation); Microsoft Defender XDR ise Behavior:Linux/CopyFailExploit.A imzasını taşıyor.

# 1. AF_ALG sistem çağrılarının yakınında beklenmedik sudo/setuid çağrıları için auth.log
sudo grep -E 'session opened for user root' /var/log/auth.log* | \
  awk '{print $1, $2, $3, $11}' | sort | uniq -c | sort -rn | head -20

# 2. Açıklama tarihinden bu yana yeni veya değiştirilmiş setuid ikilileri
sudo find / -xdev -perm -4000 -newer /etc/shadow -mtime -30 \
  -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

# 3. Son 30 gündeki algif_aead modül yükleme olayları
sudo journalctl --since "30 days ago" | grep -E 'algif_aead|algif_skcipher'

# 4. Falco kuralı referansı (helm chart aracılığıyla dağıtın)
# https://github.com/falcosecurity/rules — kural adı: "Unexpected AF_ALG Socket Creation"
falcoctl artifact install copy-fail-rules

Bir bulgu çıkarsa — dağıtmadığınız yeni bir setuid ikili veya beklenmedik bir kullanıcıya bağlı algif_aead yükleme olayı — bunu doğrulanmış bir ihlal olarak ele alın. Kimlik bilgilerini döndürün, host'u izole edin, olay müdahale ekibinize iletin ve GDPR'ın 72 saatlik bildirim saatinin başlayıp başlamadığını değerlendirin. Aşırı tepki vermenin bedeli bir bakım penceresi; yetersiz tepki vermenin bedeli ise kariyerinizin önümüzdeki 18 ayı.

Sertleştirme: Bir Sonraki Çekirdek CVE'sini Sıkıntısız Atlatmak

Copy Fail, RuntimeDefault'u aşan son çekirdek CVE'si olmayacak. Bu çeyrek yapabileceğiniz ve bir sonrakini daha az acı verici kılacak altı şey:

• Minimum çekirdek modülü yüzeyi. Kullanmıyorsanız algif_*, bluetooth, dccp, tipc, sctp, cifs'i kara listeye alın. Çoğu iş yükü bunlara ihtiyaç duymuyor.
• Her iş yükünde varsayılan-reddet seccomp. Localhost profillerini norm haline getirin. RuntimeDefault tavan değil, tabandır.
• İmaj tabanlı node yenileme (Talos Linux, Bottlerocket, Flatcar). Atomik yeniden başlatma, değişmez çekirdek, sorunsuz geri alma.
• Çalışma zamanı izleme. Falco veya Tetragon, beklenmedik sistem çağrılarını gerçek zamanlı olarak yakalıyor. Sistem çağrısı yüzeyi daha geniş olan yapay zeka iş yükleri için çalışma zamanı gözlemlenebilirliğiyle eşleştirin.
• Kısa ömürlü çekirdek modülü yükleme olayları SIEM'inizde alarm oluşturmalı. Buna ihtiyaç duymayan bir üretim host'unda algif_aead yüklenirse bunu saniyeler içinde bilmeniz gerekiyor.
• K8s sürümlerini ve node imajlarını aktif olarak güvenlik takibi yaptığınız bir temel sürüme sabitleyin. Kayan etiketler, bekleyen bir olaydır.

Copy Fail'in bize bir sonraki açık düşmeden öğrettikleri bunlar. Bir sonraki sıfır gün açığını 60 yerine 30 dakikada çözecek ekipler, bu altı kontrolü zaten hayata geçirmiş olanlardır.

Sık Sorulan Sorular

Copy Fail (CVE-2026-31431)'den etkileniyor muyum?

1 Mayıs 2026 öncesinde yayımlanmış bir çekirdekle herhangi bir büyük Linux dağıtımı çalıştırıyorsanız ve ayrıcalıksız shell erişimine izin veriyorsanız, büyük olasılıkla evet. Çok kiracılı her makine, her Kubernetes worker'ı ve her CI runner bu kapsama giriyor. uname -r komutunu çalıştırın ve yukarıdaki yamalı sürüm tablosuyla karşılaştırın. CVSS skoru 7,8.

PSS Restricted ile Kubernetes küme zafiyetli mi?

Evet. seccompProfile.type: RuntimeDefault ile Pod Security Standards Restricted, socket(AF_ALG, ...) çağrısını engellemiyor. Juliet.sh bunu doğrudan test etti: PSS Restricted artı RuntimeDefault ile çalışan bir pod, Copy Fail aracılığıyla host çekirdeğini ele geçirdi. Yukarıdaki K8s hafifletme bölümünde sağlanan Localhost seccomp profiline ihtiyacınız var.

Docker Desktop Copy Fail'i engelliyor mu?

Docker Desktop'ın varsayılan seccomp profili pek çok sistem çağrısını reddediyor, ancak moby/moby PR #52501 yayımlanana kadar AF_ALG'yi engellemiyor. Yamalı profili içeren bir Docker sürümüne (Docker 29.x backport) güncelleyin ya da seccomp profilini manuel olarak uygulayın. Bu güncellemesiz Linux Docker kurulumları hâlâ açık duruyor.

RuntimeDefault seccomp bunu durduruyor mu?

Hayır. RuntimeDefault, değiştirilmemiş container çalışma zamanı profilidir (Docker/containerd varsayılanı). Meşru iş yükleri zaman zaman çekirdek kripto API'sini kullandığından socket(AF_ALG, ...) çağrısına izin veriyor. Çözüm, AF_ALG'yi açıkça reddeden bir Localhost profilidir (tam JSON K8s bölümünde) ya da moby/moby PR #52501 varsayılanına yükseltmektir.

Şu an çekirdeği yeniden başlatamıyorsam ne yapmalıyım?

Modprobe kara listesi ve socket(AF_ALG, ...) çağrısını reddeden Localhost seccomp profili, yama yapana kadar yeterlidir. Her ikisi de yeniden başlatma gerektirmeden uygulanır. /etc/modprobe.d/copy-fail.conf dosyasına blacklist algif_aead ekleyin, rmmod algif_aead çalıştırın, seccomp profilini dağıtın ve bir sonraki bakım penceresinde yeniden başlatın.

Copy Fail vahşi ortamda istismar ediliyor mu?

5 Mayıs 2026 itibarıyla Microsoft'un tehdit istihbaratı yazısı vahşi ortamda istismarı doğrulamıyor; ancak Xint'in yayımladığı 732 baytlık exploit göz önüne alındığında hatayı "son derece kolayca silahlandırılabilir" olarak nitelendiriyor. İstismar ilksel sınıfı (splice yoluyla sayfa önbelleği yazımı), açıklamanın ardından haftalar içinde yaygın biçimde istismar edilen Dirty Pipe (CVE-2022-0847) ile örtüşüyor.

Copy Fail yapay zeka/ML iş yüklerini özellikle etkiliyor mu?

Evet, orantısız biçimde. Self-hosted çıkarım (vLLM, sglang, Ollama), ajan çalışma ortamları, MCP sunucuları ve ML imajları için CI derlemeleri rutin olarak güvenilmeyen kullanıcı kodunu çalıştırıyor. PSS Restricted üzerinde bile bir container içindeki bunların herhangi biri Copy Fail'i tetikleyerek host'u ele geçirebilir. GPU node'ları genellikle çok kiracılı olduğundan en yüksek risk profilini taşıyor.

Copy Fail ile Dirty Pipe arasındaki fark nedir?

Her ikisi de rastgele sayfa önbelleği yazmalarına yol açan Linux çekirdeği LPE açıkları, ancak tetikleme yüzeylerı farklı: Dirty Pipe splice()'ı bir pipe'a kötüye kullandı, Copy Fail ise splice()'ı bir algif_aead (AF_ALG) soketine kötüye kullanıyor. Her ikisi de standart container seccomp varsayılanlarını atlıyor. Copy Fail'in farkı: AF_ALG yolu, RuntimeDefault ile Pod Security Standards Restricted üzerinden erişilebilir.

Sonuç

Copy Fail, rehberi uçtan uca uygularsanız yaklaşık 60 dakikada yamanabilir: modprobe kara listesi, çekirdek güncellemesi, seccomp profili, doğrulama. Kubernetes ve yapay zeka altyapısı açısı bu CVE'yi rutin bir LPE'den farklı kılan şey: PSS Restricted ve RuntimeDefault sizi kurtarmıyor ve güvenliği ele geçirilmiş tek bir çıkarım pod'u host'u ele geçirebilir. Modprobe kara listesi ve Localhost seccomp profili kombinasyonu, yamadan sonra da kalıcı savunmadır.

Olay müdahale runbook'unuza ikinci bir göz atmamızı ya da bir sonraki çekirdek CVE düşmeden önce sertleştirilmiş bir K8s temeli oluşturmamızı ister misiniz? Techsy ile iletişime geçin. Üretim yapay zeka/ML yığınları için platform sertleştirme yapıyoruz.

Son güncelleme: 2026-05-05. Yeni distro danışma belgelerini 2026-05-12'de tarayacağız.