Use-After-Free TCP Linux: Patch atau Mitigasi?

Kernel Anda punya use-after-free yang bisa dijangkau dari jarak jauh di jalur handshake TCP, distro Anda belum merilis perbaikan, dan seseorang sudah mendemonstrasikan exploit root yang berfungsi. Jadi apa rencananya: diam menunggu, atau mulai membuang paket di firewall? Use-after-free TCP Linux yang diungkap sebagai CVE-2026-98432 adalah studi kasus yang bersih untuk keputusan tertua dalam operasi keamanan, yaitu patch versus mitigasi. Jawaban jujurnya: kedua opsi itu sama sekali tidak simetris. Salah satunya benar-benar memperbaiki masalahnya.

Saya pernah berada di kedua sisi keputusan ini. Saya pernah menunda rollout kernel darurat karena mitigasinya kelihatan cukup baik di atas kertas, dan saya juga pernah melihat aturan firewall "sementara" membusuk diam-diam di produksi selama delapan bulan, sementara semua orang lupa CVE yang ditutupinya. Bug ini adalah pemicu yang bagus untuk membahas kapan tiap pendekatan menang, karena trade-off-nya di sini sangat jelas.

Apa Sebenarnya Use-After-Free TCP Itu

Mekanismenya penting karena itulah yang menentukan apa yang bisa dan tidak bisa dilakukan sebuah mitigasi. Saat server Anda menerima koneksi TCP IPv4, kernel melacak handshake yang belum selesai dalam request socket yang ringan, lalu mempromosikannya menjadi socket penuh setelah handshake selesai. Jika header IPv4 dari peer membawa options, kernel menyimpannya untuk digemakan kembali dalam balasannya. Bug-nya: kernel memberikan options yang tersimpan itu ke koneksi baru tanpa menyalinnya, lalu langsung membebaskannya, padahal CPU lain masih bisa membacanya untuk menyusun balasan handshake. Itu use-after-free, bisa dijangkau oleh peer jarak jauh yang tidak perlu autentikasi, bahkan sebelum satu baris kode aplikasi Anda berjalan.

Perbaikan upstream dari Eric Dumazet terdiri dari empat baris: dua panggilan kfree() biasa diubah menjadi kfree_rcu(), yang menunda pembebasan memori sampai semua pembaca selesai menggunakannya. Ini adalah perbaikan kanonik kernel untuk kelas bug seperti ini. Pembaca di bawah RCU memegang referensi yang tidak terlihat, jadi Anda membiarkan grace period habis sebelum mengklaim kembali memorinya. CNA kernel sendiri memberi skor CVSS 9.8. Red Hat awalnya memberi 8.1, lalu menaikkannya menjadi 9.8 Critical pada 30 Oktober, dengan alasan tidak adanya prasyarat jaringan.

Dua detail mengubah perhitungan eksposur. Pertama, race ini gagal dengan elegan: percobaan yang gagal hanya menggagalkan handshake tanpa membuat mesin panic, sehingga penyerang bisa mencoba berulang kali tanpa batas. Kedua, jalur exploit yang didemonstrasikan Anthropic menargetkan host dengan listener multipath TCP. Menurut Go Security Team, program Go membuka listener MPTCP secara default di Linux sejak Go 1.24, selama kernel mengizinkan. Periksa armada Anda:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Output ss -M yang kosong berarti tidak ada listener MPTCP. Tapi jangan merasa aman dulu. Tim Go menegaskan bahwa bug yang mendasarinya tidak spesifik MPTCP. Ini adalah UAF generik dalam pemrosesan handshake; MPTCP hanya jalur yang sudah terbukti bisa dieksploitasi dari ujung ke ujung.

Jalur Patch: Kernel Diperbaiki, Reboot, Selesai

Patching terasa membosankan untuk dijelaskan karena ini satu-satunya opsi yang benar-benar menghilangkan kerentanan, bukan sekadar mengubah bentuknya. Kernel yang sudah diperbaiki dirilis upstream pada 11 dan 15 Oktober untuk setiap lini stabil yang masih dipelihara. Bug ini sudah ada sejak Linux 4.4, artinya banyak sistem long-tail terdampak, termasuk kernel yang terlalu tua sehingga upstream tidak mau menyentuhnya.

Masalahnya ada di reboot. Update kernel tidak berpengaruh sampai mesin boot ke kernel baru, dan di situlah biaya operasional yang sebenarnya muncul: node Kubernetes yang harus dikosongkan, latihan failover, database primary yang tidak ada orang mau restart di jam kerja. Itulah mengapa "tinggal patch" selalu benar sebagai saran tapi tidak pernah cukup. Anda butuh rencana rollout: host kanari dulu, lalu tier stateless, lalu tier stateful dengan jendela pemeliharaan. Jika Anda pernah menjalani rotasi kernel darurat untuk seluruh armada, Anda sudah tahu caranya. Tim yang menangani ini dengan baik adalah tim yang berlatih mengosongkan node saat tidak ada yang terbakar. Kebiasaan rekayasa defensif yang Anda bangun di hari-hari tenang itulah yang berguna saat ada 9.8.

Satu jebakan yang perlu disebut: dpkg -l atau rpm -q kernel yang menampilkan paket sudah diperbaiki tidak berarti apa-apa jika kernel yang sedang berjalan masih versi lama. uname -r memberi tahu apa yang benar-benar berjalan. Di keluarga RHEL, needs-restarting -r akan memberi tahu dengan jelas apakah reboot masih tertunda. Saya pernah meninjau laporan pasca-insiden di mana armada yang "sudah di-patch" ternyata armada kernel yang terpasang tapi tidak berjalan. Verifikasi versi yang berjalan terhadap tracker distro Anda, bukan angka upstream, karena kernel distro membawa backport di bawah penomoran versinya sendiri.

Jalur Mitigasi: Buang IPv4 Options, Nonaktifkan MPTCP

Mitigasi sementara yang dipublikasikan adalah aturan nftables yang membuang paket TCP IPv4 masuk yang membawa IP options, yaitu kondisi pemicu untuk jalur yang rentan. Anda bisa melengkapinya dengan menonaktifkan MPTCP (sysctl -w net.mptcp.enabled=0) jika Anda tidak memakainya. Keduanya cepat, tanpa reboot, dan bisa di-deploy lewat manajemen konfigurasi dalam satu sore. Di situlah daya tariknya.

Sekarang bagian yang seharusnya meredam antusiasme Anda: buletin Red Hat sendiri menyebut aturannya "mengurangi eksposur terhadap kerentanan ini tetapi tidak dapat sepenuhnya mencegahnya." Baca kalimat itu dua kali. Mitigasi mempersempit permukaan serangan; ia tidak menutupnya. Paket dengan IP options memang jarang dalam lalu lintas normal, dan kebanyakan middlebox memang membuangnya, yang menjadi salah satu alasan mengapa eksploitasi lewat internet terbuka dianggap tidak mungkin. Tapi "jarang" dan "mustahil" itu berbeda, dan bug ini ada di kode handshake generik, bukan hanya di jalur options yang kebetulan diuji seseorang.

Ada juga biaya yang lebih halus: mitigasi menciptakan rasa tertutup yang palsu. Tiket dipindah ke "hampir selesai", urgensi usaha patching ikut menguap, dan enam minggu kemudian Anda masih menjalankan kernel rentan di balik packet filter, dengan ingatan institusional tentang alasannya yang makin pudar. Saya pernah menulis tentang pola ini dalam konteks jendela CVE kritis PHP, di mana tim yang langsung mematikan komponen rentan hasilnya lebih baik dibanding tim yang menumpuk filter yang cerdas. Pelajarannya sama, stack-nya berbeda.

Patch vs Mitigasi: Kapan Masing-Masing Menang

Berikut skor jujur saya, setelah bertahun-tahun membuat keputusan ini di bawah tekanan.

• Kernel yang sudah diperbaiki tersedia untuk distro Anda. Patch menang telak. Debian, SUSE Enterprise, Oracle UEK, dan Amazon Linux sudah merilis perbaikan. Tidak ada mitigasi yang lebih cerdas daripada perbaikan upstream empat baris. Jadwalkan reboot, rollout bertahap per ring, lalu lanjut.
• Belum ada kernel yang diperbaiki, eksposur nyata. Mitigasi sekarang juga, karena inilah tujuan mitigasi. Ubuntu dan RHEL masih berstatus "Vulnerable"/"affected" pada akhir Oktober. Jika Anda menghadap internet dengan listener MPTCP, buang paket IP-options dan nonaktifkan MPTCP hari ini, sambil melacak kernel yang diperbaiki seperti rilis yang Anda blokir.
• Menghadap internet tapi berada di balik front door terkelola. Urgensi Anda turun. Panduan AWS, bahwa lalu lintas yang difrontkan oleh load balancer, CloudFront, atau API Gateway mereka tidak sampai ke instance Anda sebagai TCP mentah yang tidak tepercaya, masuk akal. Tetap mitigasi (murah), lalu patch dalam siklus normal, bukan siklus darurat.
• Sistem single-core atau single-queue. Prioritas lebih rendah. Race ini butuh pemrosesan paket bersamaan di banyak CPU. Embedded dan VM kecil mendapat napas lega, tetapi mereka juga cenderung menjadi mesin yang tidak pernah di-reboot, jadi jangan biarkan "prioritas rendah" berubah menjadi "tidak pernah".
• Kernel yang sudah end-of-life (upstream di bawah 5.10). Mitigasi adalah satu-satunya opsi yang tidak bergantung pada upstream. Inilah skenario di mana mitigasi benar-benar menang, karena alternatifnya adalah backport dari vendor yang mungkin tidak pernah datang. Ini juga sinyal keras bahwa mesinnya sendiri adalah kerentanan, dan perbaikan yang sebenarnya adalah menggantinya.

Celah Distro Adalah Cerita Sebenarnya

Detail yang seharusnya mengusik Anda bukan bug-nya. Perbaikan UAF empat baris masuk ke kernel stabil setiap bulan. Yang mengusik adalah dua distribusi server terbesar di dunia, Ubuntu dan RHEL, masih belum merilis perbaikan lebih dari dua minggu setelah upstream, sementara Amazon Linux sudah mem-patch setiap kernelnya dan AlmaLinux, rebuild komunitas, sudah punya kernel yang diperbaiki di tahap pengujian sebelum upstream. Komunitas HN memperhatikan dan mereka benar untuk kesal: ini adalah distribusi yang paling gencar memasarkan diri sebagai siap untuk server.

Bagi praktisi, pelajarannya tidak glamor: jendela eksposur Anda ditentukan oleh pipeline backport vendor Anda, bukan upstream. Itu mengarah ke dua hal. Pertama, ketahui URL tracker distro Anda dan benar-benar pantau. CVE ini sempat berstatus "Received" di NVD tanpa analisis, sementara CNA kernel, Red Hat, dan distro semuanya sudah punya halaman detail. Kedua, perlakukan responsivitas distro sebagai kriteria pemilihan. Amazon Linux baru saja menunjukkan pipeline perbaikan kernel yang jauh lebih cepat daripada dua incumbent. Itu tidak akan berarti di slide pemasaran, tetapi berarti sekali saat 9.8 muncul di akhir pekan Halloween.

Exploit yang Ditulis AI Mengubah Jam

Kalimat paling berdampak dalam pengungkapan ini mudah terlewat: Anthropic melaporkan bahwa model Claude-nya menghasilkan exploit remote-root yang berfungsi, setelah prompt awal, dengan waktu kurang dari satu jam mesin untuk berpindah dari kebocoran pointer kernel ke root shell. Mereka belum mempublikasikannya, dan skeptis di HN bersenang-senang dengan bingkai "trust me bro". Wajar. Tapi meski sudah dikurangi karena unsur pemasaran, arahnya jelas: jarak antara "diff masuk ke stable tree" dan "exploit yang berfungsi ada" makin menyempit, karena hambatan menulis exploit tidak pernah ada di bug-nya, melainkan di manusia yang bisa membaca diff dan melakukan heap grooming.

Ini memampatkan jendela keputusan patch-versus-mitigasi. Ketika pengembangan exploit butuh berminggu-minggu, "mitigasi sekarang, patch di jendela pemeliharaan berikutnya" masih bisa dibenarkan. Ketika sebuah model bisa menghasilkan PoC dalam semalam dari commit publik, fase mitigasi Anda harus diukur dalam jam, dan fase patching dalam hari. Perbaikan empat baris itu publik. Siapa pun bisa mempelajarinya. Anggap exploit-nya juga sudah ada.

Rekomendasi Saya

Patch. Mitigasi hanya sebagai jembatan, dan beri tanggal kedaluwarsa pada jembatan itu. Konkretnya: jika distro Anda sudah punya kernel yang diperbaiki, mulai rollout sekarang dan verifikasi uname -r setelah setiap reboot. Jika Anda memakai Ubuntu atau RHEL, terapkan buang IP-options dan nonaktifkan MPTCP hari ini, lalu perlakukan ketiadaan perbaikan kernel sebagai dependensi pemblokir dan cek tracker setiap hari, bukan setiap minggu. Prioritaskan apa pun yang menghadap internet dengan listener MPTCP, lalu semua yang menerima TCP masuk, yang hampir semuanya. Container tidak menyelamatkan Anda; mereka berbagi kernel host, jadi patch node-nya.

Pelajaran yang lebih dalam adalah yang diajarkan bug ini setiap beberapa tahun dengan nomor CVE baru: mitigasi membeli waktu, tetapi hanya patch yang menutup lubang, dan waktu yang dibeli mitigasi makin pendek. Bangun kemampuan untuk rollout kernel yang cepat dan aman sebelum Anda membutuhkannya, karena perbaikan empat baris berikutnya sudah ada di antrean seseorang.