CVE-2026-98432: Use-After-Free TCP IPv4 di Kernel Linux, CVSS 9.8

CVE-2026-98432 adalah use-after-free di handshake TCP IPv4 kernel Linux dengan skor CVSS 3.1 sebesar 9.8 (Critical), dan bisa dijangkau penyerang remote tanpa kredensial apa pun. Perbaikannya sudah masuk upstream sejak 11 dan 15 Oktober 2026, sedangkan kernel yang terpengaruh mencakup semua rilis dari Linux 4.4 sampai di bawah versi yang dipatch. Masalahnya bukan pada kernel upstream, tapi pada distribusi: sampai 29 Oktober 2026, Ubuntu masih menandai kernelnya "Vulnerable" di semua rilis, dan Red Hat mencantumkan RHEL 8, 9, serta 10 sebagai terdampak tanpa perbaikan.

TL;DR

• CVE-2026-98432 adalah use-after-free di request socket handshake TCP IPv4, dinilai kernel CNA sebesar CVSS 3.1 9.8 Critical.
• Rilis yang sudah diperbaiki: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, dan 7.3. Bug-nya ada sejak kernel 4.4.
• Peneliti Anthropic melaporkan bug ini, dan menyebut model Claude menulis eksploit root remote untuk server yang membuka listener Multipath TCP.
• Perbaikannya cuma dua baris: kfree() diganti kfree_rcu() supaya memori tidak dibebaskan saat CPU lain masih membacanya.
• Kontainer tidak menyelamatkan apa pun. Kontainer memakai kernel host, jadi mengganti image tanpa memperbarui host tidak menutup celah.

Apa yang sebenarnya rusak di handshake TCP?

Bug-nya ada di cara kernel menyimpan opsi IPv4 selama handshake setengah jadi. Saat server menerima koneksi TCP, kernel mencatat handshake di sebuah request socket yang ringan, lalu membuat socket penuh ketika handshake selesai. Kalau header IPv4 dari peer membawa opsi, kernel menyimpan opsi itu untuk dikembalikan di balasan. Kesalahannya: opsi tersebut diserahkan dari request socket ke koneksi baru tanpa disalin, lalu langsung dibebaskan ketika koneksi berakhir, padahal CPU lain masih bisa membaca memori yang sama untuk menyusun balasan handshake. Membaca memori kernel yang sudah dibebaskan itulah use-after-free.

Yang membuat ini berat: peer tidak perlu login, dan seluruh prosesnya terjadi di dalam penanganan handshake kernel, sebelum kode aplikasi mana pun berjalan. Catatan penilaian kernel CNA menyebut dampaknya bisa berupa isi heap kernel yang terbaca oleh peer remote, korupsi memori kernel, atau mesin yang crash. Red Hat memilih penilaian lebih rendah, CVSS 3.1 8.1 dengan attack complexity High, dan menyebut dampak utamanya crash atau potensi korupsi memori. Selisih skor itu wajar, tapi bukan alasan untuk menunda patch, karena eksploit laboratorium Anthropic menunjukkan remote root shell pada setidaknya satu konfigurasi.

Versi kernel mana yang sudah aman?

Perbaikannya masuk ke jalur stabil dalam dua gelombang. Linux 7.2.10 dan 6.18.56 keluar 11 Oktober 2026, disusul 6.12.113, 6.6.159, 6.1.190, 5.15.223, dan 5.10.272 pada 15 Oktober 2026, lalu 7.3 pada 18 Oktober 2026. Commit perbaikannya adalah e3f33b0, berjudul "ipv4: free inet_opt and ireq_opt after an RCU grace period", ditulis Eric Dumazet dan me-review Kuniyuki Iwashima, dengan kredit pelapor untuk Xinyang Ge dari Anthropic.

Jalur rilis	Status	Versi perbaikan	Tanggal
7.3	Mainline	7.3	18 Oktober 2026
7.2	Stable	7.2.10	11 Oktober 2026
6.18	Longterm	6.18.56	11 Oktober 2026
6.12	Longterm	6.12.113	15 Oktober 2026
6.6	Longterm	6.6.159	15 Oktober 2026
6.1	Longterm	6.1.190	15 Oktober 2026
5.15	Longterm	5.15.223	15 Oktober 2026
5.10	Longterm	5.10.272	15 Oktober 2026
4.4 sampai 5.4	End-of-life upstream	Tidak ada, hanya lewat distro	-

Satu hal yang sering bikin salah paham: kernel distribusi membawa perbaikan backport dengan nomor versi sendiri. Artinya nomor kernel yang terpasang di server Debian, Ubuntu, atau RHEL tidak bisa dibandingkan langsung dengan nomor upstream. Yang benar adalah melihat tracker distribusi masing-masing, bukan nomor kernel.org.

Distribusi mana yang belum punya perbaikan?

Per 29 Oktober 2026 pukul 20:00 CDT, Ubuntu belum menerbitkan perbaikan untuk rilis mana pun. Tracker-nya masih menulis "Vulnerable" untuk paket linux di 26.10, 26.04, 24.04, dan 22.04, dengan catatan "work in progress" di 7.3.0-10.10, 7.0.0-43.43, 6.8.0-149.149, dan 5.15.0-203.213, sementara 20.04, 18.04, dan 16.04 hanya berstatus "Vulnerable". Belum ada Ubuntu Security Notice untuk CVE ini. Red Hat juga belum punya perbaikan untuk RHEL 8, 9, dan 10 serta OpenShift Container Platform 4, dan menyatakan mitigasinya "tidak tersedia atau opsi yang ada tidak memenuhi kriteria" mereka. RHEL 6 dan 7 tidak terdampak.

Distribusi	Status per 29 Oktober 2026	Versi perbaikan
Debian 12 bookworm	Sudah diperbaiki	6.1.190-1 dan 6.12.113-1~deb12u1
Debian 13 trixie	Sudah diperbaiki	6.12.113-1
SUSE Linux Enterprise 16.0	Sudah diperbaiki	kernel-default 6.12.0-160000.40.1
Oracle Linux UEK 7 sampai 10	Sudah diperbaiki	ELSA-2026-500397, 500398, 500399
Amazon Linux 2023 kernel6.12 dan kernel6.18	Sudah diperbaiki	ALAS2023-2026-3335 dan ALAS2023-2026-3251
Ubuntu semua rilis	Belum ada perbaikan	-
RHEL 8, 9, 10	Belum ada perbaikan	-
Amazon Linux 2 dan kernel default AL2023	Pending fix	-

Bagaimana cara memeriksa server sendiri?

Periksa kernel yang benar-benar berjalan, bukan hanya paket yang terpasang, dan lakukan dari host, bukan dari dalam kontainer. Urutan perintah berikut cukup untuk Debian, Ubuntu, dan turunan RHEL.

uname -r
uname -v
dpkg -l 'linux-image*' | grep ^ii
rpm -q kernel
needs-restarting -r

Kalau versi kernel yang terpasang lebih baru daripada yang sedang berjalan, artinya perbaikan belum aktif dan mesin perlu reboot. Ini kesalahan yang paling sering terjadi saat patch darurat: paket sudah terpasang, tapi kernel lama masih hidup di memori. Untuk memeriksa apakah ada listener Multipath TCP, yang menurut Anthropic menjadi syarat eksploit mereka, jalankan pemeriksaan berikut pada host dan node Kubernetes.

ss -Mlnp
sysctl net.mptcp.enabled

Hasil kosong dari ss -Mlnp berarti tidak ada listener MPTCP. Nilai net.mptcp.enabled = 1 saja tidak cukup untuk menyimpulkan ada listener, karena aplikasi tetap harus membuka socket MPTCP secara eksplisit. Server yang punya listener MPTCP masuk urutan paling atas daftar patch, karena itu konfigurasi yang dipakai eksploit laboratorium Anthropic untuk mendapatkan root remote.

Kalau belum bisa patch, apa yang bisa dilakukan?

Red Hat tidak menerbitkan mitigasi resmi, jadi yang bisa dipakai adalah aturan sementara berbasis saran penilaian CNA: penyerang mengirim opsi IPv4 Record Route atau Timestamp di SYN. Lalu lintas TCP yang wajar hampir tidak pernah membawa opsi IPv4, sehingga membuang paket TCP yang memilikinya nyaris tidak menimbulkan biaya. Aturan nftables berikut memblokir paket TCP dengan header IPv4 lebih dari 20 byte, yaitu panjang minimum tanpa opsi.

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

Aturan ini berjalan sebelum connection tracking, tidak menyentuh IPv6 maupun lalu lintas non-TCP, dan hilang setelah reboot. Aturan ini bukan perbaikan kernel, dan belum diuji terhadap eksploit nyata, tapi ia menutup vektor yang dijelaskan penilaian CNA sampai jadwal reboot ke kernel yang sudah dipatch tersedia. Kalau firewall tepi bisa membuang paket IPv4 dengan opsi, lakukan di sana supaya semua host di belakangnya ikut terlindungi.

Seberapa nyata ancamannya sekarang?

Anthropic menyatakan bahwa model Claude menulis eksploit tersebut "setelah prompt awal", dan eksploit itu menjalankan perintah arbitrer sebagai root tanpa kredensial maupun interaksi pengguna, pada server dengan listener Multipath TCP. Dalam proof of concept mereka, prosesnya butuh 48 menit untuk membocorkan pointer kernel, lalu lima menit lagi untuk mencapai eksekusi perintah shell. Eksploitnya sendiri belum dipublikasikan, dan kebijakan pengungkapan Anthropic memberi pengembang 90 hari untuk patch plus 45 hari sebelum detail di luar advisory publik dibahas.

Sampai 29 Oktober 2026, delapan repositori GitHub sudah merujuk CVE ini. Sebagian besar mendeskripsikan diri sebagai alat audit atau mitigasi, termasuk sebuah peran Ansible dan sebuah livepatch untuk AlmaLinux serta Rocky Linux. Satu repositori yang dibuat pukul 19:22 menyebut isinya mencakup pemicu race. CVE ini belum masuk katalog Known Exploited Vulnerabilities milik CISA per tanggal tersebut, dan uji publik mana pun belum diverifikasi independen. Yang jelas: kalah dalam race hanya membuat handshake gagal tanpa crash, sehingga penyerang tekun bisa mencoba berulang kali sampai berhasil. Itu alasan mengapa skor Red Hat yang lebih rendah tidak berarti aman.

Bagaimana menyusun urutan patch untuk tim kecil?

Mulai dari inventaris kernel, bukan dari daftar CVE. Catat kernel yang berjalan di setiap host, lalu tandai mana yang membuka listener Multipath TCP dan mana yang menjalankan kontainer. Dua penanda itu menentukan prioritas, karena host dengan listener MPTCP adalah target yang paling mungkin dipakai penyerang, sementara host berkontainer berarti satu kernel menanggung banyak layanan sekaligus.

Setelah prioritas jelas, jadwalkan reboot dalam satu gelombang. Perbaikan kernel tidak aktif sampai mesin boot ke kernel baru, jadi host yang paketnya sudah diperbarui tapi belum reboot masih rentan. Menggabungkan reboot ke satu jendela pemeliharaan lebih murah daripada beberapa reboot terpisah, dan sekaligus menutup celah antara "paket terpasang" dan "perbaikan aktif".

Terakhir, verifikasi setelah reboot. Jalankan uname -r lalu bandingkan hasilnya dengan tracker distribusi, bukan dengan nomor upstream. Langkah ini terlihat sepele, tapi justru di sinilah banyak host tetap rentan berhari-hari karena diasumsikan sudah aman hanya karena paketnya sudah terpasang.

Sumber dan bacaan lanjut

• Catatan resmi CVE-2026-98432 di cve.org, tempat nomor CVE pertama kali dipublikasikan 15 Oktober 2026.
• Commit perbaikan e3f33b0 di git.kernel.org, dengan diff dua baris pada dua berkas.
• Tracker distribusi: Ubuntu dan Red Hat.
• Rilis kernel stabil resmi di kernel.org.
• Analisis lengkap yang menjadi sumber angka di artikel ini: Atlas Security.

FAQ

Apakah container terlindungi dari CVE-2026-98432?

Tidak. Kontainer berbagi kernel dengan host, jadi seluruh jalur handshake TCP yang rentan tetap berjalan di kernel host. Mengganti image, menambah lapisan sandbox, atau memindahkan aplikasi ke Podman maupun Docker tidak mengubah kernel yang mengeksekusi kode jaringan tersebut. Yang harus diperbarui adalah kernel host dan node Kubernetes.

Apakah IPv6 juga terdampak?

Untuk masalah utama, tidak. Commit perbaikan menyebut secara eksplisit bahwa IPv6 tidak terpengaruh oleh isu pertama. Namun commit yang sama juga memperbaiki masalah serupa pada migrasi request socket, dan menyatakan kasus IPv6 terkait akan ditangani di patch terpisah. Pantau rilis stabil berikutnya untuk jalur tersebut.

Kenapa perbaikannya cuma dua baris tapi tetap berat?

Karena yang diubah adalah waktu pembebasan memori, bukan logika fitur. Mengganti dua pemanggilan kfree() menjadi kfree_rcu() membuat pembebasan menunggu semua pembaca selesai, dan itulah inti perbaikannya. Ukuran diff tidak berkorelasi dengan tingkat keparahan, karena yang menentukan adalah seberapa mudah jalur tersebut dijangkau penyerang remote.

Apa itu Fragnesia yang disebut di artikel sumber?

Fragnesia adalah perbaikan kernel Linux lain pada Oktober 2026 yang juga baru aktif setelah reboot, dan dilaporkan sedang dirangkai dengan PHP2Shell untuk mendapatkan root. Kalau satu host punya dua celah yang sama-sama butuh reboot, jadwalkan satu reboot untuk keduanya, dan pastikan urutan patch tidak menunda salah satunya terlalu lama.

Di mana memantau status perbaikan resmi?

Pantau tracker distribusi, bukan nomor kernel upstream: Ubuntu di ubuntu.com/security/CVE-2026-98432, Red Hat di access.redhat.com/security/cve/CVE-2026-98432, Debian di security-tracker.debian.org, dan catatan resmi CVE di cve.org. Rilis kernel resmi ada di kernel.org. Jangan berpegang pada nomor versi mentah tanpa mencocokkannya dengan backport distribusi.