Fork me on GitHub

Bedah CVE-2026-98432: Use-After-Free di Kernel Linux yang Bikin Ubuntu (dan Semua Distro Lain) Panik

Posted by Mahyuddin Susanto on October 31, 2026 · 14 mins read

Beberapa hari terakhir linimasa infosec rame ngomongin satu CVE baru di kernel Linux: CVE-2026-98432. Skornya CVSS 9.8 (Critical), remote, tanpa autentikasi, tanpa interaksi user. Buat orang yang kerja di balik layar server Ubuntu (atau distro apapun), ini jenis bug yang bikin on-call harus begadang.

Berhubung latar belakang saya dulu networking & Linux, saya coba bedah bug ini sedetail mungkin: kenapa bisa kejadian, gimana alur seranganya, efek dan dampaknya, apakah cuma Ubuntu yang kena, sampai apa yang mestinya dilakukan system engineer dan IT manager begitu notifikasi CVE ini masuk inbox.

Apa itu CVE-2026-98432?

CVE-2026-98432 adalah bug use-after-free (UAF) di stack IPv4/TCP kernel Linux, tepatnya di penanganan IP options (Record Route dan Timestamp) pada saat TCP three-way handshake. Bug ini direservasi 25 September 2026, dipublikasikan 15 Oktober 2026, dan detail root cause-nya baru dibahas terbuka di milis oss-security pada 30 Oktober 2026.

Bug ini berdampak di level ring-0 karena ada di kernel, dan jalur kodenya dilewati sebelum ada autentikasi apapun: tepatnya saat kernel memproses paket SYN yang masuk ke listener TCP yang aktif.

Kenapa bug ini bisa terjadi (root cause)

Supaya enak dibayangkan, ini alurnya secara sederhana:

  1. Saat client mengirim SYN yang membawa IP option (Record Route / Timestamp), kernel menyimpan option tersebut ke sebuah request socket (reqsk) melalui pointer bernama ireq_opt.
  2. Begitu handshake selesai dan koneksi “naik kelas” jadi socket anak (child socket), fungsi tcp_v4_syn_recv_sock() memindahkan kepemilikan pointer ireq_opt tadi ke inet_opt milik child socket, tanpa menyalin (copy) datanya. Jadi satu buffer yang sama dipakai bersama antara request socket lama dan child socket baru.
  3. Masalahnya, sejak kernel mengadopsi arsitektur di mana request socket diproses tanpa memegang listener lock (perubahan ini sudah ada sejak lama, commit 079096f103fa), bisa saja CPU lain secara bersamaan memproses retransmisi SYN untuk request socket yang sama, lalu mencoba mengirim SYNACK lewat tcp_v4_send_synack().
  4. Fungsi-fungsi pembaca ini (tcp_v4_send_synack(), inet_csk_route_req(), ip_build_and_send_pkt(), ip_options_build()) membaca ireq_opt hanya dengan proteksi rcu_read_lock(). Di sisi lain, destructor-nya, inet_sock_destruct(), membebaskan inet_opt dengan kfree() biasa, bukan kfree_rcu().
  5. Karena destructor tidak menunggu RCU grace period, ada window waktu dimana satu CPU sedang membebaskan (free) buffer opsi tadi, sementara CPU lain masih membacanya untuk membangun paket SYNACK. Inilah use-after-free-nya.

Singkatnya, ini murni race condition antara proses pembuatan child socket/teardown koneksi di satu sisi, dan proses retransmisi SYN di sisi lain, ditambah kelalaian memakai mekanisme RCU-safe free di jalur yang sudah RCU-read di sisi lainnya. Masalah serupa juga ditemukan pada fitur request socket migration (net.ipv4.tcp_migrate_req=1, atau saat memakai program eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE), yang juga menggunakan kfree() biasa di tcp_v4_reqsk_destructor().

Perbaikannya sendiri relatif sederhana secara kode: pindah dari kfree() ke kfree_rcu() pada kedua destructor tadi, konsisten dengan pola yang sudah dipakai di jalur lain yang mengganti inet_opt (seperti do_ip_setsockopt()). Tapi walaupun fix-nya kecil, window bug ini sudah terbuka sejak IPv4 request socket diproses tanpa listener lock, artinya ini bug lama yang baru “ketahuan” sekarang.

Seberapa parah dampaknya?

CVE ini dapat skor CVSS 3.1: 9.8 (Critical) dengan vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Kalau diterjemahkan:

  • Remote, tanpa privilege, tanpa interaksi user: penyerang cukup punya akses jaringan ke port TCP yang listening (misalnya web server, SSH, atau layanan apapun yang terima koneksi TCP).
  • Confidentiality tinggi: setelah buffer opsi di-reclaim (dipakai ulang) oleh alokasi lain, ip_options_build() bisa menyalin isi memori “bekas” tadi ke dalam paket SYNACK yang dikirim ke penyerang, sehingga isi heap kernel yang berdekatan bisa bocor keluar lewat jaringan.
  • Integrity tinggi: offset-offset lama (srr, rr, ts) dari objek yang sudah di-reclaim bisa dipakai untuk mengarahkan operasi memcpy atau penulisan alamat di ip_options_build(), berpotensi jadi out-of-bounds write di kernel.
  • Availability tinggi: nilai optlen yang sudah basi bisa membuat ip_build_and_send_pkt() memanggil skb_push() melebihi kapasitas headroom, memicu skb_under_panic(), alias kernel panic atau crash.

Rentang skenario yang mungkin terjadi dari satu bug ini cukup luas: mulai dari denial of service (server crash berulang), kebocoran data sensitif dari memori kernel, sampai memory corruption yang berpotensi dieksploitasi lebih lanjut jadi remote code execution, meski mengeksploitasi UAF kernel untuk RCE penuh biasanya tetap butuh teknik heap-grooming yang tidak sepele. Untuk sekadar bikin server down atau mengintip memori kernel, eksploitasinya realistis dibuat.

Apakah ini cuma berdampak ke Ubuntu?

CVE-2026-98432 bukan bug khas Ubuntu, dan bukan patch Canonical. Ini bug di upstream Linux kernel itu sendiri, tercatat di berkas net/ipv4/af_inet.c dan net/ipv4/tcp_ipv4.c, dan menjangkau rentang versi kernel yang sangat lebar.

Artinya, semua distribusi Linux yang menjalankan kernel versi terdampak berpotensi kena, bukan cuma Ubuntu:

  • Debian dan turunannya
  • RHEL, CentOS Stream, Rocky Linux, AlmaLinux
  • Fedora
  • openSUSE/SUSE
  • Arch Linux
  • Android (yang basisnya kernel Linux) pada kernel versi terdampak
  • Bahkan perangkat jaringan/embedded berbasis Linux (router, NAS, IoT) kalau kernelnya belum di-backport patch-nya

Yang membedakan hanya kapan dan bagaimana tiap vendor merilis patch backport-nya. Ubuntu, Debian, RHEL, dan sebagainya masing-masing punya tim security yang akan menyiapkan paket kernel baru begitu patch upstream tersedia, tapi root cause dan risikonya sama persis karena datang dari kode kernel yang sama.

Catatan tambahan dari deskripsi upstream: IPv6 tidak terdampak oleh isu pertama ini, karena tcp_v6_syn_recv_sock() memang sudah menyalin (duplicate) opsi, bukan memindahkan pointer-nya. Tapi untuk skenario request socket migration, IPv6 punya potensi isu serupa pada ipv6_opt (dipakai CALIPSO) yang menurut catatan upstream akan ditangani di patch terpisah. Jadi kalau di jaringan Anda IPv6 dominan dan fitur migrasi reqsk tidak dipakai, eksposurnya untuk CVE spesifik ini lebih kecil, tapi tetap perlu update kernel begitu patch tersedia.

Versi kernel yang terdampak

Berdasarkan data CVE record resmi, kernel dianggap tidak terdampak (sudah mengandung fix) mulai versi berikut:

Branch Versi aman mulai
5.10.x 5.10.272
5.15.x 5.15.223
6.1.x 6.1.190
6.6.x 6.6.159
6.12.x 6.12.113
6.18.x 6.18.56
7.2.x 7.2.10
7.3 sudah termasuk fix sejak awal

Semua versi dari 4.4 ke atas, di bawah angka-angka tersebut, berstatus affected. Untuk Ubuntu, ini berarti hampir semua rilis LTS yang masih didukung (20.04, 22.04, 24.04, 26.04) berpotensi terdampak tergantung kernel branch dan patch level yang mereka pakai (termasuk varian linux-generic, linux-hwe, linux-aws, linux-gke, dan seterusnya).

Per tulisan ini dibuat, saya belum menemukan nomor USN (Ubuntu Security Notice) resmi yang secara spesifik menyebut CVE-2026-98432, wajar mengingat detail root cause-nya baru dipublikasikan ke publik 30 Oktober 2026. Jangan jadikan ini sebagai tanda Ubuntu aman: cek berkala halaman resmi ubuntu.com/security/CVE-2026-98432 dan Ubuntu Security Notices untuk status per-rilis begitu Canonical menerbitkan USN-nya, karena dengan skor 9.8 kemungkinan besar ini akan jadi prioritas tinggi untuk di-backport segera.

Bagaimana cara mencegah atau mitigasi?

Karena ini bug di jalur inti penanganan paket TCP SYN, mitigasi yang paling solid tetap patching kernel, bukan workaround. Tapi berikut yang bisa dilakukan:

  1. Update kernel ke versi yang sudah fix sesuai tabel di atas, atau ke paket kernel distro yang sudah membawa backport patch kfree_rcu() tersebut.
  2. Pantau rilis USN/DSA/errata dari distro masing-masing (Ubuntu, Debian, RHEL, dan seterusnya), karena backport biasanya datang lebih cepat daripada menunggu minor version upstream naik.
  3. Filter atau drop paket dengan IP options di edge/firewall, khususnya Record Route dan Timestamp option, kalau memang tidak dibutuhkan di jaringan Anda. Banyak jaringan modern sudah men-drop paket ber-IP-option secara default karena jarang dipakai secara legit, jadi ini mengurangi permukaan serangan walau bukan fix permanen.
  4. Untuk fitur net.ipv4.tcp_migrate_req, kalau tidak benar-benar dipakai (misalnya untuk load balancing SO_REUSEPORT tingkat lanjut), pertimbangkan nonaktifkan sementara sampai kernel terpatch, karena jalur ini juga kena isu yang sama di sisi migrasi request socket.
  5. Live patching (misalnya Canonical Livepatch untuk Ubuntu, atau kpatch/kgraft di ekosistem RHEL/SUSE) supaya bisa tambal kernel tanpa reboot, penting untuk server yang sulit dijadwalkan downtime-nya.
  6. Pastikan monitoring kernel (dmesg, syslog, crash dump) aktif untuk mendeteksi gejala awal seperti kernel oops/panic yang berulang di sekitar proses TCP handshake, karena bisa jadi indikasi percobaan eksploitasi atau sekadar crash tidak sengaja akibat bug ini.

Apa tindakan kita sebagai system engineer?

Kalau Anda yang pegang server sehari-hari, ini daftar langkah konkretnya:

  1. Inventarisasi versi kernel di seluruh fleet: fisik, VM, container host (ingat, container berbagi kernel host, jadi host-nya yang harus dipatch, bukan image container-nya).
  2. Cek status CVE per server lewat uname -r lalu cocokkan ke tabel versi aman di atas, atau pakai tools seperti pro security-status (Ubuntu Pro), apt list --upgradable, atau vulnerability scanner internal.
  3. Prioritaskan server yang paling terekspos: edge-facing server (web, VPN, reverse proxy, mail), baru kemudian server internal.
  4. Terapkan patch lewat jalur resmi (apt update && apt upgrade untuk Ubuntu/Debian, atau mekanisme patch management internal) begitu paket kernel terbaru tersedia. Jangan menunggu siklus patching reguler kalau ini masuk kategori critical.
  5. Jadwalkan reboot atau rolling restart untuk server yang tidak pakai live patching, dengan koordinasi downtime minimal (rolling per node di belakang load balancer).
  6. Uji dulu di staging sebelum rollout masif, terutama kalau Anda pakai kernel custom/HWE/patched khusus untuk hardware tertentu (NIC driver, dan sebagainya).
  7. Dokumentasikan hasil remediasi (server mana sudah dipatch, kapan, versi berapa) untuk kebutuhan audit/compliance.
  8. Setelah patch, lakukan verifikasi: pastikan service tetap jalan normal dan tidak ada regresi jaringan. Karena ini menyentuh jalur TCP options, ada baiknya test koneksi yang memanfaatkan path MTU discovery/timestamp TCP juga.

Apa tindakan kita sebagai IT manager?

Dari sisi manajerial, fokusnya ada di manajemen risiko dan koordinasi, bukan detail teknis:

  1. Klasifikasikan ini sebagai insiden/kerentanan prioritas tinggi mengingat skor CVSS 9.8 dan sifatnya remote-unauthenticated. Ini bukan kasus yang cukup diberi SLA patching standar (30-90 hari), tapi harus masuk jalur emergency patching, idealnya kurang dari 7 hari untuk sistem yang terekspos internet.
  2. Minta laporan eksposur dari tim engineering: berapa banyak server/sistem yang terdampak, mana yang internet-facing, apa rencana dan timeline remediasinya.
  3. Pertimbangkan investasi Ubuntu Pro atau dukungan livepatch kalau belum punya, khususnya untuk server produksi kritikal. Biaya langganan jauh lebih murah dibanding downtime atau insiden kebocoran data.
  4. Siapkan komunikasi ke stakeholder (manajemen atas, klien, auditor) kalau sistem yang kena termasuk yang memproses data sensitif atau punya kewajiban kepatuhan (PCI-DSS, ISO 27001, dan sebagainya). Regulator atau auditor biasanya menanyakan bukti remediasi vulnerability kritikal seperti ini.
  5. Evaluasi proses change management: pastikan ada jalur cepat (expedited change) untuk emergency security patching tanpa harus menunggu siklus CAB (Change Advisory Board) mingguan/bulanan biasa.
  6. Jangan anggap ini selesai setelah Ubuntu dipatch. Kalau organisasi juga punya server berbasis distro lain (RHEL, Debian, dan sebagainya), bahkan perangkat jaringan/appliance berbasis Linux, pastikan semuanya masuk daftar remediasi, bukan cuma yang disebut di judul CVE atau berita yang dibaca tim.
  7. Masukkan ke dalam post-mortem/lessons learned internal: apakah proses monitoring CVE sudah cukup cepat menangkap isu seperti ini, apakah ada gap di asset inventory, dan sebagainya.

Kesimpulan

CVE-2026-98432 menunjukkan kenapa defense in depth itu penting: bug-nya ada di jalur paling dasar networking kernel Linux (penanganan TCP handshake dan IP options), dengan dampak potensial dari DoS, kebocoran memori kernel, sampai memory corruption, semuanya tanpa butuh autentikasi atau interaksi user. Karena ini bug di upstream kernel, bukan patch Ubuntu semata, semua distro Linux yang menjalankan kernel versi terdampak perlu melakukan hal yang sama: update begitu patch tersedia.

Buat system engineer, saatnya cek inventaris kernel dan jalankan patching darurat; buat IT manager, pastikan proses emergency patching itu benar-benar berjalan, bukan cuma ada di dokumen kebijakan.

Referensi


Related Posts

← Previous Post