Lubang Kernel Linux Skor 9,8: Kisah CVE-2026-98432 yang Ditemukan AI

Bismillahirrohmanirohim..

Tanggal 15 Oktober 2026 tidak masuk trending topic mana pun. Tapi di daftar NVD ada satu entri baru yang menurut saya layak disimpan di catatan: CVE-2026-98432, sebuah use-after-free di penanganan koneksi TCP IPv4 kernel Linux, dengan skor CVSS 3.1 sebesar 9,8 — kategori critical. Angka segitu di kernel yang dipakai hampir semua VPS, hampir semua container, dan hampir semua hypervisor yang kita kelola sendiri… ya, bikin saya berhenti sebentar dan mengecek satu hal: kernel server ini versi berapa.

Oke, mari saya ceritakan duduk perkaranya. Bukan untuk bikin panik, tapi karena minggu ini ada dua hal menarik yang bertemu di satu bug: Linux dan AI.

Apa Sebenarnya yang Bocor di Kernel

Bayangkan kernel perlu menempelkan “catatan kecil” pada setiap permintaan koneksi: opsi IP semacam Record Route atau Timestamp yang dikirim penyerang di paket SYN. Catatan itu disimpan di sebuah struct bernama ireq_opt.

Masalahnya begini. Saat koneksi naik dari request socket ke child socket, tcp_v4_syn_recv_sock() memindahkan tangan catatan itu ke socket anak — tanpa menyalinnya. Kalau di saat yang sama datang SYN kiriman ulang untuk request yang sama, CPU lain bisa mengirim SYNACK sambil membaca catatan yang sama. Bila socket anak sudah selesai dan dibuang, catatannya ikut dibebaskan dengan kfree() biasa, sementara CPU lain masih menunjuk ke sana. Itulah use-after-free.

Nama patch upstream-nya cukup menjelaskan semuanya: “ipv4: free inet_opt and ireq_opt after an RCU grace period”, commit e3f33b0a di Linux 7.3-rc7. Perbaikannya kecil saja — mengganti kfree() dengan kfree_rcu() di dua tempat. Kecil, tapi dampaknya besar: sejak commit 079096f103fa (“tcp/dccp: install syn_recv requests into ehash table”), request socket diproses tanpa memegang listener lock, jadi tidak ada lagi yang mencegah socket anak dibebaskan saat SYNACK masih dibangun.

Ada varian kedua lewat migrasi request socket (net.ipv4.tcp_migrate_req=1), yang membuat socket lama dan klonnya berbagi ireq_opt yang sama. Menurut deskripsi resmi CVE-nya, efeknya bisa berlapis: membocorkan isi heap kernel ke lawan bicara, menulis di luar batas lewat ip_options_build(), sampai membuat kernel oops.

Yang perlu dicatat: semuanya terjadi sebelum autentikasi aplikasi. Peer hanya perlu mengirim SYN dengan opsi IPv4 yang valid — tidak perlu login, tidak perlu interaksi korban. Kernel 4.4 ke atas terdampak. Perbaikannya tersedia di 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, dan 7.3.

Sisi Lain Cerita: AI yang Menemukan Duluan

Ini bagian yang menurut saya paling menarik, dan bukan karena sensasinya. Anthropic mempublikasikan riset berjudul Discovering and exploiting vulnerabilities in critical, real-world software with Claude. Di sana dijelaskan bagaimana Claude membaca kode, menyusun hipotesis, lalu berhasil membangun zero-click remote code execution di Linux dengan memanfaatkan UAF yang sama: buffer di-overflow, pointer callback ditimpa alamat payload yang sudah disiapkan di memori kernel, dan rangkaian panggilan itu berakhir dengan perintah shell berjalan sebagai root.

Di laporan yang sama ada juga temuan lain: out-of-bounds read di implementasi QUIC kernel Windows (CVE-2026-33096) yang bisa membuat server restart berulang hanya dengan beberapa paket.

Saya tidak sedang menakut-nakuti. Bagian yang penting justru ini: perbaikannya sudah masuk upstream dan di-backport ke semua cabang kernel stabil yang masih dirawat. Yang berubah, menurut saya, adalah kecepatan penemuan. Bug kelas ini dulu butuh peneliti dengan jam terbang tinggi dan berbulan-bulan waktu. Sekarang sebuah model bisa menyisir kode dan mencoba banyak dugaan dalam hitungan jam. Kalau penemuan makin cepat, kebiasaan menambal kita juga harus ikut naik — bukan sebaliknya.

Kenapa VPS Kecil Ikut Kena: MPTCP dan Go

Ada twist yang membuat cerita ini nyambung ke tumpukan software yang kita pakai sehari-hari. Pada 29 Oktober 2026, tim keamanan Go mengirim pengumuman di golang-announce (diteruskan ke milis oss-security pada 30 Oktober) dengan isi yang cukup tegas.

Sejak Go 1.24, program Go mengaktifkan MPTCP secara default untuk listen socket di Linux. Eksploit yang didemonstrasikan Anthropic memang memakai server dengan listener MPTCP. Tapi — dan ini poin pentingnya — bug-nya bukan bug MPTCP. Sistem tanpa listener MPTCP pun, menurut tim Go, mungkin rentan terhadap serangan sejenis.

Mitigasi sementara yang mereka sebut: setel GODEBUG=multipathtcp=0 saat runtime, atau tambahkan baris godebug multipathtcp=0 di go.mod saat build. Tapi tim Go sendiri menyebut cara ini rapuh, karena satu listener saja yang terlewat tetap membuka celah. Rekomendasi utama mereka tetap satu: naikkan versi kernel. Diskusi lanjutannya ada di go.dev/issue/82717.

Kenapa ini relevan buat kita? Karena banyak alat self-hosted favorit di artikel-artikel blog ini ditulis dengan Go — Gitea, Traefik, dan sederet alat lain. Artinya “bug kernel” bisa berubah jadi “masalah aplikasi” tanpa kita menyentuh aplikasinya sama sekali.

Cek Kernel, bukan Cek Perasaan

Cara memeriksanya sederhana, dan ini satu perintah saja:


uname -r

Kalau nomor kernelmu sudah menyentuh salah satu versi yang saya sebut di atas — atau lebih baru — berarti perbaikannya sudah ada. Server tempat saya menulis artikel ini mengeluarkan 7.0.14-25-pve, dan itu bukan angka asal: kernel Proxmox dibangun dari sumber kernel Ubuntu, dan menurut diskusi di forum Proxmox, perbaikan ini masuk lewat sumber Ubuntu 7.0.0-43.43.

Beberapa catatan praktisnya:

Proxmox: kernel pertama yang memuat perbaikan adalah 7.0.14-25-pve. Versi 7.0.14-24 dan sebelumnya belum. Keduanya, 7.0.14-25 dan 7.0.14-26, tersedia di repo no-subscription dan test.
Proxmox Backup Server memakai paket kernel yang sama, jadi urusannya identik.
Container LXC memakai kernel host. Menambal host berarti menambal semua container di atasnya sekaligus — ini salah satu alasan saya lebih suka LXC untuk layanan ringan.
VM tidak ikut otomatis. Kernel di dalam VM harus diperbarui sendiri, dari dalam VM-nya.
Setelah update kernel, reboot hampir selalu perlu. Tanpa reboot, kernel lama yang tetap berjalan.

Kenapa Tracker Selalu Terasa Terlambat

Di sinilah saya jadi sedikit mengeluh, wajar saja ya. Halaman keamanan Ubuntu menandai 26.04 LTS masih “Vulnerable work in progress in 7.0.0-43.43”, 24.04 LTS di 6.8.0-149.149, dan 22.04 LTS di 5.15.0-203.213.

Sekilas terbaca seperti “belum ditambal”. Padahal menurut penjelasan di thread forum Proxmox, kode perbaikannya sudah ada di sumber 7.0.0-43 — status work in progress itu berarti Canonical belum menandai rilisnya sebagai selesai, bukan berarti kodenya belum masuk.

Pelajaran yang saya ambil: kalau mau memastikan, baca rantai commit-nya — upstream, backport distro, lalu versi paket — jangan cuma percaya badge status. Bukan karena trackernya buruk, tapi karena tracker adalah ringkasan, dan ringkasan selalu kalah detail dari catatan aslinya.

Yang Saya Ambil dari Pekan Ini

Tiga hal, dan semuanya sederhana.

Pertama, kerentanan kernel itu urusan rutin, bukan drama. Yang membedakan server yang aman dan yang tidak sering kali bukan alat mahal, melainkan kebiasaan: cek, tambal, reboot, dan jadwalkan reboot itu di jam sepi.

Kedua, angka CVSS itu alat prioritas, bukan kebenaran tunggal. Kernel.org memberi 9,8 (Critical) di CVSS 3.1, sementara Ubuntu mencatat 8,3 di CVSS 4.0 dengan vektor AT:P — artinya butuh kondisi balapan yang tidak selalu mudah. Dua-duanya jujur, konteksnya saja berbeda. Yang tidak boleh: memakai angka rendah sebagai alasan menunda tanpa membaca detailnya.

Ketiga, pemilik satu VPS pun perlu membaca changelog. Bukan karena kita punya tim keamanan, tapi justru karena kita tidak punya.

Minggu ini dunia keamanan sedang ribut soal AI yang menemukan lubang di kernel. Bagi saya, kesimpulannya justru menenangkan: perbaikan sudah tersedia, dan mengeceknya cuma butuh satu perintah. Silakan buka terminal, jalankan uname -r, lalu putuskan sendiri apakah server kita butuh satu reboot malam ini.

Terima kasih sudah membaca sampai di sini — semoga server kita semua tetap tenang, dan rebooting-nya selalu di jam yang tepat.

Assalamu’alaikum warrohmatullahi wabarookaatuh..