CVE-2026-98432 Linux TCP Açığı: Sunucuları Koruma

CVE-2026-98432 nedir?

CVE-2026-98432, Linux işletim sistemlerinin çekirdeği olan Linux kernel'de bulunan bir güvenlik açığıdır. Resmî başlığı ipv4: free inet_opt and ireq_opt after an RCU grace period şeklindedir ^[1]. Kaydı Linux çekirdeği CVE ekibi atadı ve 15 Ekim 2026'da yayımladı ^[1]. Kayıtta açığa 9,8 CVSS 3.1 temel puanı verilmiş olup bu puan Kritik düzeydedir ^[1].

Açık bir use-after-free (serbest bırakıldıktan sonra kullanım) hatasıdır: program, serbest bıraktığı bir bellek parçasını kullanmaya devam eder; oysa bu bellek artık başka veriler içeriyor olabilir. Bu örnekte hata, gelen IPv4 TCP bağlantı isteklerini işleyen kodda yer alıyor ^[10]. CVSS vektörü AV:N/AC:L/PR:N/UI:N şeklindedir. Bu, saldırının ağ üzerinden çalıştığı, karmaşıklığının düşük olduğu, herhangi bir yetki ya da kullanıcı etkileşimi gerektirmediği anlamına gelir ^[1].

Hata, 079096f103fa commit'iyle geldiği Linux 4.4'ten beri mevcuttur ^[2]. Eric Dumazet'in yazdığı düzeltme 5 Ekim 2026'da commit edildi ve artık ana hat (mainline) çekirdekte yer alıyor ^[3]. Düzeltme, bakımı süren kararlı dallara da geri taşındı ^[2][4].

Hangi sistemleri etkiliyor?

Red Hat'e göre açık, IPv4 TCP ağı etkin olan ve savunmasız bir çekirdek çalıştıran her sistemi etkiliyor. Gelen TCP bağlantılarını kabul eden sistemler en doğrudan risk altında olanlardır ^[6]. AlmaLinux, güvenilmeyen ağlardan IPv4 TCP bağlantısı kabul eden her sistemin açıkta kabul edilmesini öneriyor ^[10]. IPv6 ana sorundan etkilenmiyor ^[2].

Güvenlik açığı nasıl işliyor?

Bir TCP bağlantısı el sıkışmayla başlar. İstemci bir SYN paketi gönderir, sunucu SYN-ACK ile yanıt verir ve istemci bunu onaylar. Bir SYN paketi, IP başlığındaki isteğe bağlı ek alanlar olan IPv4 seçeneklerini taşıyabilir. Record Route ve Timestamp bunlara iki örnektir ^[1].

Çekirdeğin açıklamasına göre tcp_v4_syn_recv_sock() işlevi, kaydedilmiş seçenekleri kopyalamadan yeni alt sokete devrediyor ^[2]. Bu sırada başka bir CPU çekirdeği aynı istek için yeniden gönderilmiş bir SYN'i işleyip bu seçenekleri okuyan bir SYN-ACK oluşturabiliyor ^[2]. SYN-ACK hâlâ oluşturulurken alt soketin serbest bırakılmasını engelleyen hiçbir şey yok. Soketin seçenekleri sıradan bir kfree() ile serbest bırakıldığından çekirdek, ip_options_build() içinde serbest bırakılmış belleği okuyor ^[2].

Benzer ikinci bir yarış durumu, istek soketi taşıma özelliği net.ipv4.tcp_migrate_req=1 veya bir BPF reuseport programı aracılığıyla açıldığında ortaya çıkıyor ^[2]. Düzeltme, inet_sock_destruct() ve tcp_v4_reqsk_destructor() içinde kfree_rcu() kullanarak her iki serbest bırakma yolunun da bir RCU bekleme süresini (grace period) beklemesini sağlıyor ^[2]. RCU (read-copy-update), hiçbir okuyucu belleği kullanmıyor olana kadar belleğin serbest bırakılmasını geciktiren bir çekirdek tekniğidir.

Bir saldırgan bununla ne yapabilir?

CVE kaydındaki puanlama notları üç etkiyi tanımlıyor ^[1]:

• Bilgi ifşası: serbest bırakılan bellek başka veriler tarafından yeniden kullanılabilir ve içeriği saldırgana geri gönderilen SYN-ACK'e kopyalanabilir ^[1].
• Bellek bozulması: eskimiş uzunluk ve ofset değerleri, çekirdeğin sınırların dışına yazmasına yol açarak kontrol akışını bozma potansiyeli taşır ^[1].
• Çökmeler: yeniden kullanılan bir uzunluk değeri kernel panic'i tetikleyebilir; başıboş yazmalar da çekirdeği çökertebilir ^[1].

Red Hat, zamanlamaya bu kadar duyarlı bir hata üzerinden güvenilir biçimde kod çalıştırmanın hassas bir heap kontrolü gerektirdiğini ekliyor. Yine de herhangi bir ağ ön koşulu olmadığı ve ciddi kararsızlığa yol açabildiği için hatayı Kritik olarak derecelendiriyor ^[7].

Anthropic neyi açıkladı ve MPTCP'nin rolü ne?

27 Ekim 2026'da Anthropic'in Frontier Red Team ekibi, Claude modellerini kullanarak bulduğu güvenlik açıklarını anlatan bir rapor yayımladı ^[4][11]. Ekip, CVE-2026-98432 için uzaktaki bir saldırganın Multipath TCP (MPTCP) dinleyicisi olan Linux sunucularında kimlik bilgisi ya da kullanıcı etkileşimi olmadan root olarak istediği komutu çalıştırmasını sağlayan bir istismar kodu geliştirdiğini söylüyor ^[4]. MPTCP, tek bir bağlantının aynı anda birden fazla ağ yolunu kullanmasına olanak tanıyan bir TCP uzantısıdır.

Anthropic iki aşama tarif ediyor. İstismar önce çekirdeğin adres rastgeleleştirmesi olan KASLR'yi aşmak için bir çekirdek işaretçisini sızdırıyor. Ardından bir geri çağırma (callback) işaretçisinin üzerine yazarak çekirdeğin saldırganın seçtiği bir komutu root olarak çalıştırmasını sağlıyor ^[4]. Kaybedilen bir yarış yalnızca el sıkışmayı başarısız kılıyor ve sistemi çökertmiyor; bu nedenle saldırgan denemeye devam edebiliyor ^[4]. Anthropic'in kavram kanıtında bir çekirdek işaretçisini sızdırmak 48 dakika, komut çalıştırmak ise 5 dakika daha sürdü ^[4].

MPTCP gerekli mi?

Açığı değerlendiren üreticilere göre hayır. Red Hat, MPTCP'nin bu açık için zorunlu bir koşul olmadığını ve MPTCP'si devre dışı olan sistemlerin de etkilendiğini belirtiyor ^[6]. Go güvenlik ekibi, gösterilen istismarın bir MPTCP dinleyicisine ihtiyaç duyduğunu, ancak temeldeki hatanın MPTCP'ye özgü olmadığını söylüyor ^[5]. Go'nun burada önemi şu: Go 1.24'ten bu yana Go programları Linux'ta dinleyen soketler için MPTCP'yi varsayılan olarak etkinleştiriyor ^[5].

Akamai'ye göre Anthropic root istismar kodunu yayımlamadı; Akamai 2 Kasım 2026'da çalışan herkese açık bir istismar kodundan haberdar olmadığını açıkladı ^[11].

Hangi çekirdek sürümleri ve dağıtımlar düzeltildi?

Çekirdek CVE ekibi şu upstream düzeltmeleri listeliyor: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ve ana hat 7.3 ^[2]. Ancak çoğu kişi, kendi sürüm numaralarını kullanan dağıtımının derlediği bir çekirdeği çalıştırır. Upstream numaralarını karşılaştırmak yerine dağıtımınızın güvenlik bültenine bakın.

3 Kasım 2026 itibarıyla durum:

• Red Hat Enterprise Linux: RHEL 8, 9 ve 10 için düzeltilmiş çekirdekler 1 Kasım 2026'da yayımlandı. RHEL 6 ve 7 etkilenmeyenler arasında listeleniyor. RHEL 9 gerçek zamanlı çekirdeği ve OpenShift düğüm imajları hâlâ etkilenen olarak listeleniyor ^[7].
• Ubuntu: Ubuntu sorunu Kritik olarak derecelendiriyor. Takip sayfası 26.10, 26.04 LTS, 24.04 LTS ve 22.04 LTS sürümlerini düzeltmeleri devam eden savunmasız sürümler olarak gösteriyor; 20.04, 18.04 ve 16.04 de savunmasız, 14.04 ise etkilenmeyen olarak listeleniyor ^[8].
• Debian: Debian 12 bookworm (linux 6.1.190-1 ve linux-6.12 6.12.113-1~deb12u1), Debian 13 trixie (linux 6.12.113-1) ve unstable için düzeltmeler mevcut ^[9].
• AlmaLinux: AlmaLinux 8, 9 ve 10 için düzeltilmiş çekirdekler üretim depolarında yer alıyor ^[10].
• Diğerleri: Akamai, SUSE, Oracle Linux ve Amazon Linux 2023'ün 30 Ekim 2026'ya kadar bazı sürümler için düzeltilmiş çekirdekler yayımladığını bildirdi ^[11].

Android telefonlar ne durumda?

Android, Linux çekirdeğini kullanıyor; ancak 2 Kasım 2026'da yayımlanan Android Güvenlik Bülteni CVE-2026-98432'yi listelemiyor ^[13]. Telefon sahipleri, üreticileri yayımladıkça güvenlik güncellemelerini yüklemelidir.

Bir sunucunun savunmasız olup olmadığı nasıl kontrol edilir?

1. Çalışan çekirdeği bulun. uname -r komutunu çalıştırın. Bir düzeltme ancak makine yeni çekirdekle yeniden başlatıldıktan sonra geçerli olur. AlmaLinux, kullanıcılara sistemi yeniden başlatmalarını ve sürümü uname -r ile doğrulamalarını söylüyor ^[10].
2. Üreticinizin takip sayfasıyla karşılaştırın. Dağıtımınızın güvenlik sayfasında CVE-2026-98432'yi arayın. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] ve AlmaLinux ^[10], düzeltmeyi içeren paket sürümlerini ayrı ayrı listeliyor.
3. MPTCP'yi kontrol edin. sysctl net.mptcp.enabled MPTCP'nin açık olup olmadığını gösterir. sudo ss -lnMp ise MPTCP dinleyicilerini ve bunlara sahip süreçleri listeler ^[10]. Akamai ayrıca net.ipv4.tcp_migrate_req değerinin kontrol edilmesini öneriyor ^[11].
4. Go servislerini arayın. Go 1.24 veya sonrasıyla derlenen Go programları Linux'ta varsayılan olarak MPTCP dinleyicileri açar ^[5]. Bu nedenle çalıştırdığınız her Go servisi, Anthropic'in istismar ettiği yolu açığa çıkarıyor olabilir.
5. Üstüne kurulu ürünleri kontrol edin. Red Hat, OpenShift, OpenStack ve Red Hat Virtualization dahil RHEL çekirdeği üzerine kurulu her ürünün de etkilenebileceği konusunda uyarıyor ^[6].

CVE-2026-98432 nasıl düzeltilir veya etkisi nasıl azaltılır?

Gerçek çözüm, yamalı bir çekirdektir. Red Hat çekirdek güncellemelerini uygulamayı tek eksiksiz çözüm olarak tanımlıyor ^[6]; Go güvenlik ekibi de en iyi çözümün yamalı bir çekirdeğe yükseltmek olduğunu söylüyor ^[5]. Dağıtımınızın çekirdek güncellemesini kurun, sistemi yeniden başlatın ve çalışan sürümü doğrulayın.

Yama gelmeden önce ne yapabilirsiniz?

• IPv4 seçenekleri içeren TCP paketlerini düşürün. Red Hat'in yayımladığı ve Ubuntu'nun takip sayfasında kullanıcı katkılı geçici çözüm olarak listelenen bir nftables kuralı, IP başlığı temel 20 bayttan uzun olan, yani seçenek taşıyan gelen IPv4 TCP paketlerini düşürüyor (ip hdrlength > 5) ^[6][8]. Zaman damgaları ve pencere ölçekleme gibi normal TCP seçenekleri TCP başlığında yer aldığından etkilenmez ^[8]. Her iki üretici de kuralın riski azalttığını ancak istismarı tamamen engelleyemediğini söylüyor ^[6][8].
• Kuralın sınırlarını bilin. AlmaLinux, kendi sürümünün yeniden başlatmadan sonra kalıcı olmadığını, aynı sunucudaki konteynerler arasındaki trafiğin kuralı atlayabileceğini, yönlendirme yapan sunucularda iletilen paketleri de düşürdüğünü ve CIPSO/NetLabel etiketlerine dayanan ağları bozduğunu belirtiyor ^[10]. Ubuntu, ayrı ağ yapılandırmasına sahip konteynerlerde kuralın ayrıca uygulanması gerektiğini not ediyor ^[8].
• İhtiyacınız yoksa MPTCP'yi devre dışı bırakın. net.mptcp.enabled=0 ayarı MPTCP'yi sistem genelinde kapatır ^[10]. Akamai ayrıca net.ipv4.tcp_migrate_req=0 ayarını öneriyor ^[11]. Akamai, yalnızca MPTCP'yi devre dışı bırakmanın istismarı engellemediği, sadece yarışı tetikleme olasılığını düşürdüğü konusunda uyarıyor ^[11]. Go programları GODEBUG=multipathtcp=0 ile de bu özelliği kapatabilir, ancak Go ekibi program bazında kapatmaları kırılgan buluyor ^[5].
• Ağ sınırında filtreleyin. Red Hat, OpenShift için bir düğümdeki kuralların pod'lar arası trafiği filtrelemediğini, kümenin önündeki ağ sınırında filtreleme yapmanın ise bu sınırlamayı ortadan kaldırdığını belirtiyor ^[6].

init_on_free=1 işe yarar mı?

Bir oss-security gönderisinde ek bir geçici önlem olarak init_on_free=1 önyükleme seçeneği önerildi. CIQ'daki çekirdek ekibinin bir üyesi, bunun bu CVE'yi anlamlı ölçüde hafifletmediğini ve güvenlik bültenlerinde ağırlık taşımaması gerektiğini yanıtladı ^[12]. Bunu bu hataya karşı bir önlem olarak değil, genel bir sağlamlaştırma adımı olarak görün.

CVE-2026-98432 istismar ediliyor mu?

3 Kasım 2026 itibarıyla CVE-2026-98432, ABD hükümetinin gerçek dünyada istismar edildiği doğrulanmış açıkları listelediği CISA Bilinen İstismar Edilen Güvenlik Açıkları kataloğunda yer almıyor ^[14]. Akamai 2 Kasım 2026'da çalışan herkese açık bir istismar kodundan haberdar olmadığını söyledi ^[11]. Bu, hatayı kimsenin istismar etmediğinin kanıtı değildir. Güvenilir bir istismar kodunun var olduğu gösterildi ^[4] ve teknik ayrıntılar çekirdek düzeltmesinde herkese açık ^[3].

Ciddiyet tablosu da zaman içinde değişti. CVE ilk olarak 15 Ekim 2026'da yayımlandı ^[1]. Daha geniş ilgi, Anthropic'in 27 Ekim tarihli raporunun ardından geldi ^[4][11]. Geçici önlemler içeren üretici bültenleri 29 Ekim ile 2 Kasım arasında yayımlandı ^[5][6][10]. İlk kaydı hızlıca gözden geçiren yöneticiler sonraki yönergeleri kaçırmış olabilir.

Bundan sonra ne olacak?

Red Hat incelemesinin sürdüğünü ve yeni bilgiler ortaya çıktıkça bültenini güncelleyeceğini söylüyor ^[6]. RHEL 9 gerçek zamanlı çekirdeği ve OpenShift imajları ^[7] ile hâlâ üzerinde çalışılan Ubuntu çekirdekleri ^[8] gibi kalan paketlerin önümüzdeki günlerde veya haftalarda düzeltme almasını bekleyin. Haber özetleri yerine üretici takip sayfalarına bakın, çünkü bu sayfalar ilk haftalarda birkaç kez değişti.

Çekirdek düzeltmesi ilgili bir sorunu da açık bırakıyor. Çekirdek açıklamasına göre IPv6'daki tcp_v6_reqsk_destructor(), yalnızca CALIPSO tarafından ayarlanan seçeneklerde aynı taşıma sorununa sahip ve bu sorun ayrı bir yamayla ele alınacak ^[2]. Anthropic'in koordineli ifşa politikası, yama için 90 gün ve herkese açık bültenin ötesindeki ayrıntıları tartışmadan önce 45 gün daha süre tanıyor ^[4]. Bu nedenle daha fazla teknik ayrıntı ileride ortaya çıkabilir.

Bu metin genel teknik bilgi niteliğindedir; üreticinizin güvenlik bülteninin veya kurumunuzun olay müdahale sürecinin yerine geçmez.