5 Ekim'de Linux çekirdeği, çekirdek yamalarının en küçüklerinden birini aldı: IPv4 TCP kodunda iki yerde kfree() çağrısı kfree_rcu() oldu. On gün sonra çekirdek CVE ekibi CVE-2026-98432 numarasını verdi; 24 Ekim'de 9.8 puan eklendi. Debian 16 Ekim'de düzeltilmiş çekirdeğe kavuştu. Ubuntu ve Red Hat'in elinde hâlâ yama yok, tarih de yok.

Haftanın bulgusu bu ve açığı ünlü yapan manşetten daha yüksek sesle konuşuyor.

Ne bozuk

Açık, IPv4 TCP bağlantılarını kabul eden kodda — yani açık portu olan her sunucuda çalışan kodda. Tetikleyici, IPv4 seçenekleri taşıyan bir TCP SYN: özellikle Record Route veya Timestamp. Normal trafik bunları neredeyse hiç göndermez, ama bir istemciyi engelleyen bir şey de yok. Çekirdek bu seçenekleri bekleyen bağlantı isteğiyle birlikte ireq_opt içinde saklıyor. El sıkışma tamamlandığında tcp_v4_syn_recv_sock() seçenekleri kopyalamadan yeni alt sokete devrediyor; istek soketi ile alt soket aynı belleği gösteriyor. İstemci SYN'i doğru anda yeniden gönderirse başka bir CPU bunu alıp ip_options_build() içinde aynı seçeneklerden bir SYNACK kurabiliyor. Bu arada alt soket kapatılırsa inet_sock_destruct() seçenekleri düz bir kfree() ile serbest bırakıyor ve SYNACK yolu artık olmayan belleği okuyor.

Hata Linux 4.4'e (Ocak 2016) kadar uzanıyor: o sürümde istek soketleri dinleyici kilidi tutulmadan işlenmeye başladı. Bu sürümden sonraki, yamasız ve IPv4 TCP bağlantısı kabul eden her host etkileniyor; ana yol özel bir yapılandırma gerektirmiyor. Yalnızca istek soketi taşınması üzerinden giden ikinci, daha dar yol net.ipv4.tcp_migrate_req=1 ya da iliştirilmiş bir BPF programı gerektiriyor; ikisi de varsayılan olarak kapalı. IPv6 ana yolu atlıyor, çünkü orada seçenekler kopyalanıyor.

İddia

27 Ekim'de Anthropic'in Frontier Red Team'i, yayımlanmamış bir iç araştırma modelinin, Multipath TCP dinleyicisi olan sunucularda kimlik bilgisi olmadan uzaktan root olarak komut çalıştıran bir exploit yazdığını duyurdu. İki aşama: yarışı kazanmak çekirdeğe saldırganın kontrol ettiği bir uzunluk alanını okutup SYNACK'e fazladan bayt kopyalatıyor; yanıtlardan biri bir çekirdek işaretçisi taşıdığında KASLR kırılıyor. Ardından aynı hata bir tamponu taşırıp bir geri çağırma işaretçisinin üzerine çekirdek belleğinde hazır bekleyen bir yükün adresini yazıyor; çekirdek onu çağırdığında saldırganın seçtiği komut root olarak çalışıyor. Anthropic testinde adres sızıntısının 48 dakika, komut çalıştırmanın beş dakika daha sürdüğünü söylüyor.

Yazı exploit kodunu, çekirdek sürümünü ve test edilen yapılandırmayı yayımlamıyor; MPTCP dinleyicisi olmayan sunucuların da aynı yolla ele geçirilip geçirilemeyeceğini söylemiyor. TuxCare bunu yeniden üretmedi; ekim sonu itibarıyla bağımsız ve kamuya açık bir tekrar yok. İddia, çekirdek ekibinin CVE notundaki kendi değerlendirmesiyle çelişmiyor: eski seçenekler komşu çekirdek yığın belleğini karşı tarafa sızdırıyor ve sınır dışı yazmaları yönlendiriyor. Bu bir sıfır gün değil — yama CVE'den önce geldi — ama teori de değil.

MPTCP neden birden önemli

MPTCP bir bağlantının aynı anda birden çok ağ yolunu kullanmasını sağlıyor. Uygulamalar bunu ancak soket açarken isteyerek elde ediyordu, yıllarca çoğu ekip kullanmadığını varsayabilirdi. Go bunu değiştirdi: Go 1.24'ten beri Linux'ta Go programları, çekirdek destekliyorsa dinleme soketlerinde MPTCP'yi varsayılan olarak açıyor. Yani Go 1.24 veya üstüyle derlenmiş bir API geçidi, ters vekil sunucu ya da iç servis, kimsenin sipariş etmediği bir MPTCP dinleyicisi tutuyor olabilir. Go Güvenlik Ekibi'nin önlemi çalışma anında GODEBUG=multipathtcp=0 ya da derleme anında go.mod içinde godebug multipathtcp=0 satırı; ekip bunu kendisi "kırılgan" diye niteliyor, çünkü açıkta kalan tek bir dinleyici hostu savunmasız bırakıyor. Daha önemlisi, hata MPTCP'ye özgü değil ve ekibe göre MPTCP dinleyicisi olmayan sistemler de benzer saldırılara açık olabilir.

Kurumsal Linux kısmen korunuyor: RHEL 8, 9 ve 10 MPTCP kapalı geliyor; birisi net.mptcp.enabled=1 yapmadıysa Go servisi sessizce düz TCP dinleyicisine düşüyor.

Puan tartışması

Çekirdek ekibi 9.8 veriyor: ağ vektörü, yetki yok, düşük karmaşıklık — yarışın iki tarafı da saldırgan kaynaklı, çünkü SYN'i, yeniden gönderimi ve bağlantı kapatmayı o kontrol ediyor. Ubuntu aynı 9.8'i gösteriyor. Red Hat Moderate (5.9) ile başladı, 29 Ekim'de Important'a (8.1) çıktı; Oracle, SUSE ve Amazon da 8.1 veriyor. Aradaki fark tek bir ölçütte: saldırı karmaşıklığı düşük değil yüksek. Bir yarış için teknik olarak savunulabilir; kaybedilen yarışın saldırgana yalnızca bir bağlantı denemesine mal olduğu yerde ikna ediciliği azalıyor. Yama SLA'nızı satıcı önem derecesine bağladıysanız, bu CVE ekim boyunca büyük olasılıkla "orta" olarak işaretlendi.

Şimdi ne yapmalı

Önce kontrol: uname -r, sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req ve ss -H -lMn — bu komutun yazdığı her satır bir MPTCP dinleyicisidir. MPTCP'ye ihtiyaç yoksa sysctl -w net.mptcp.enabled=0, /etc/sysctl.d/ altında kalıcı hale getirin ve dinleyici açmış servisleri yeniden başlatın. Düzeltilmiş çekirdeği olmayan hostlar için ikinci katman, IPv4 seçeneği taşıyan gelen TCP paketlerini düşüren bir güvenlik duvarı kuralı: nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop. Bir exploit'e karşı test edilmedi ama belgelenen tetikleyiciyi engelliyor; yan etkiler için önce test ortamında deneyin. Sonra düzeltilmiş çekirdekler çıktıkça kurun: yeniden başlatarak ya da canlı yama ile.

Rahatsız edici kısım takvim. Koordineli açıklama burada işledi: önce yama, sonra CVE, exploit kodu açıklanmadı. Ama iki satırlık üst akış yaması önce satıcı çekirdek derlemesine, sonra pakete, sonra her açık hostta yeniden başlatmaya ya da canlı yamaya dönüşmek zorunda. Ubuntu ve Red Hat tarih vermedikçe, kurumsal sistemlerin ne kadar açık kalacağını CVSS puanı değil bu boşluk belirliyor.

Kaynaklar