Pada 2 November, Red Hat menaikkan skor CVSS celah kernel Linux CVE-2026-98432 menjadi 9,8. Sebelumnya skor yang diberikan berkisar dari 5,9 hingga 8,1, dan pada 1 November Red Hat merilis kernel perbaikan untuk RHEL 8, 9, dan 10. Status Ubuntu masih berupa perbaikan sedang dikerjakan.
Celah ini berada di alur pembentukan koneksi TCP IPv4 dan dapat dipicu dari sisi jaringan tanpa autentikasi maupun tindakan pengguna. Cakupan versi yang terdampak dimulai dari Linux 4.4, dan akar masalahnya bisa ditelusuri ke sebuah commit pada 2015.
Race condition yang diperbaiki dengan dua baris kode
Jika paket SYN membawa opsi IPv4 (misalnya Record Route atau Timestamp), kernel menyimpannya pada request socket. Ketika handshake selesai, pointer ke memori tersebut langsung diserahkan ke child socket tanpa disalin, sehingga kedua socket memakai satu salinan yang sama.
Pada saat itu, bila CPU lain sedang menyusun SYN-ACK akibat SYN yang dikirim ulang, dan child socket kebetulan dihancurkan, memori opsi langsung dibebaskan oleh kfree(). Jalur yang menyusun SYN-ACK pun membaca memori yang sudah dibebaskan.
Perbaikan diajukan oleh Eric Dumazet dengan commit e3f33b0a1d89. Ia mengganti kfree() dengan kfree_rcu() sehingga memori baru dibebaskan setelah masa tenggang RCU berlalu, dan hanya mengubah dua baris. Pelapor celah ini adalah Xinyang Ge dari Anthropic. Catatan CVE diterbitkan pada 15 Oktober. Versi perbaikan di cabang stabil adalah 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, dan 7.2.10, sedangkan di mainline perbaikannya ada pada 7.3.
Klaim Anthropic hanya bisa dibuktikan oleh Anthropic sendiri
Yang membuat celah ini menjadi sorotan adalah artikel Anthropic Frontier Red Team pada 27 Oktober. Artikel itu menyebut sebuah model internal yang belum dirilis menulis eksploit yang memungkinkan penyerang jarak jauh tanpa autentikasi menjalankan perintah sebagai root pada server dengan listener MPTCP aktif.
Eksploitasi berlangsung dalam dua tahap. Pertama, race condition dipakai untuk membaca memori kernel di luar batas, membocorkan pointer, dan melewati KASLR. Kemudian penulisan di luar batas dipakai untuk menimpa pointer fungsi callback. Anthropic menyebut waktu yang dibutuhkan sekitar 48 menit untuk membocorkan pointer, lalu sekitar 5 menit lagi untuk mendapatkan eksekusi perintah.
Ada beberapa hal yang perlu dipisahkan di sini. Kode eksploit, versi kernel yang dipakai untuk pengujian, dan konfigurasinya tidak dipublikasikan, dan belum ada verifikasi dari pihak ketiga. Catatan CVE maupun commit perbaikan tidak menyebut MPTCP, dan artikel itu juga tidak menjelaskan mengapa MPTCP diperlukan. Angka 53 menit berasal dari lingkungan yang tidak diketahui sehingga tidak bisa langsung diterapkan pada server produksi. Hingga 2 November, tidak ada vendor, CERT, maupun tim CVE kernel yang melaporkan eksploitasi di dunia nyata, dan celah ini belum masuk ke katalog Known Exploited Vulnerabilities milik CISA.
Sebagian pemberitaan berbahasa Mandarin menulis bahwa Anthropic "telah merilis contoh eksploit". Lebih tepatnya, yang dirilis adalah uraian proses eksploitasi, bukan kode yang bisa dijalankan.
Perbedaan penilaian skor juga masih ada. Tim CVE kernel dan Red Hat kini memberi 9,8, sedangkan Oracle, SUSE, dan Amazon memberi 8,1; selisihnya terletak pada apakah kompleksitas serangan dinilai rendah atau tinggi. NVD belum mengeluarkan skornya sendiri.
Go menjadikan prasyarat sebagai nilai bawaan
Pengumuman tim keamanan Go pada 29 Oktober memperluas dampaknya. Sejak Go 1.24, nilai bawaan multipathtcp adalah 2, yang berarti MPTCP hanya diaktifkan di sisi listener. Dengan kata lain, program Go yang menjalankan layanan dengan net.Listen secara bawaan sudah memenuhi prasyarat yang didemonstrasikan Anthropic.
Mitigasi dari tim Go adalah menyetel GODEBUG=multipathtcp=0 saat runtime, atau menulis godebug multipathtcp=0 di go.mod modul utama. Tim Go sekaligus menyebut cara mematikan per program ini sebagai "a fragile mitigation" (mitigasi yang rapuh), dan menilai terlalu dini untuk mengubah nilai bawaan saat ini. Di sisi kernel, net.mptcp.enabled dapat disetel ke 0, tetapi itu hanya menghilangkan prasyarat yang didemonstrasikan; celahnya sendiri tetap ada.
Yang bisa dilakukan operator lebih dulu
Status tiap distribusi (sebagian diperiksa pada 29 Oktober, sebagian pada 2 November) kurang lebih sebagai berikut:
| Distribusi | Status |
|---|---|
| RHEL 8, 9, 10 | Sudah diperbaiki |
| RHEL 9 real-time, OpenShift 4 | Terdampak, belum ada perbaikan |
| RHEL 7 | Tidak terdampak |
| Debian 12, 13 | Sudah diperbaiki |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Terdampak, perbaikan sedang dikerjakan |
| Ubuntu 16.04, 18.04, 20.04 | Terdampak, belum ada perbaikan |
| Amazon Linux 2, 2023 | Sudah diperbaiki |
| Oracle Linux (UEK) | Sudah diperbaiki |
Ubuntu memiliki porsi yang tidak kecil di antara pengguna host cloud, jadi baris inilah yang paling perlu dipantau. Sebagian besar distribusi memperbaiki lewat backport patch, sehingga untuk menilai apakah sudah teratasi, bandingkan dengan versi paket di pengumuman keamanan masing-masing; hanya melihat nomor versi utama di uname -r mudah menyesatkan. Kernel baru baru berlaku setelah reboot, dan live patch adalah mekanisme terpisah yang harus dipastikan sendiri.
Untuk mesin yang belum bisa mendapat patch, mulailah dengan mendata layanan mana saja yang mendengarkan di MPTCP, terutama biner yang dikompilasi dengan Go 1.24 atau lebih baru, lalu putuskan apakah akan dimatikan dengan cara di atas. Vendor belum mengonfirmasi bahwa mematikan MPTCP menghilangkan seluruh risiko, jadi langkah ini hanya mengulur waktu. Log crash kernel yang memuat fungsi seperti ip_options_build juga perlu diperiksa.
Sumber: kutipan publik atas artikel Anthropic Frontier Red Team, laporan kerentanan Rescana, CocoLoop, pengumuman tim keamanan Go, halaman pelacak keamanan Debian dan Red Hat. Skor dan status perbaikan per distribusi mengikuti angka yang dipublikasikan tiap vendor; detail eksploit Anthropic belum diverifikasi secara independen.