CVE-2026-98432: Celah Kernel Linux CVSS 9.8 Bisa Dipicu Lewat Paket TCP, Ubuntu dan RHEL Belum Ditambal

Oleh , Tim Engineering APIPedia · Terbit · 11 menit baca

CVE-2026-98432 adalah use-after-free di jalur TCP IPv4 kernel Linux sejak 4.4. Ubuntu dan RHEL belum punya kernel perbaikan. Ini cara cek dan meredamnya.

CVE-2026-98432: celah TCP kernel Linux dengan skor CVSS 9.8, Ubuntu dan RHEL belum ditambal

CVE-2026-98432 adalah celah use-after-free di kode kernel Linux yang menangani pembukaan koneksi TCP IPv4, dengan skor CVSS 9.8 dari tim CVE kernel. Celah ini bisa dijangkau lewat jaringan tanpa login, sebelum aplikasi apa pun menerima koneksinya, dan sudah ada di kernel sejak Linux 4.4 yang rilis awal 2016.

Perbaikannya sudah masuk ke semua cabang kernel stabil upstream, dan Debian, Oracle Linux, SUSE, serta sebagian Amazon Linux sudah merilis kernel yang ditambal. Masalahnya, per 31 Oktober 2026 Ubuntu dan Red Hat Enterprise Linux (RHEL) belum merilis kernel perbaikan, padahal keduanya paling banyak dipakai di server. Artikel ini membahas cara kerja celahnya, status tiap distro, cara mengecek server Anda, dan langkah peredam yang bisa dipasang hari ini.

Ringkasan CVE-2026-98432

AspekDetail
Jenis celahRace condition yang berujung use-after-free di handshake TCP IPv4
Fungsi terdampaktcp_v4_syn_recv_sock() dan ip_options_build()
SkorCVSS 3.1 9.8 dari tim CVE kernel dan Ubuntu; 8.1 dari SUSE, Oracle, dan advisory Red Hat; 7.0 dari Amazon; 5.9 di halaman CVE Red Hat
Kernel terdampakLinux 4.4 ke atas, sampai rilis stabil yang sudah ditambal
IPv6Tidak terdampak jalur utama
Syarat seranganBisa menjangkau port TCP yang terbuka lewat IPv4
Perbaikan upstream5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
EksploitasiExploit root jarak jauh sudah didemonstrasikan Anthropic tetapi tidak dipublikasikan; belum ada laporan serangan nyata dan belum masuk CISA KEV

Bagaimana celah ini bekerja?

Saat klien membuka koneksi TCP, kernel menyimpan dulu "permintaan setengah jadi" (request socket) sampai handshake selesai. Kalau paket SYN dari klien membawa opsi IPv4 seperti Record Route atau Timestamp, opsi itu ikut disimpan bersama request tersebut.

Begitu handshake selesai, kernel menyerahkan opsi tadi ke socket baru tanpa menyalinnya. Di saat yang sama, CPU lain bisa sedang memproses SYN kiriman ulang untuk koneksi yang sama dan membaca opsi itu untuk membangun balasan SYNACK. Kalau socket baru dihancurkan lebih dulu, opsi dibebaskan dengan kfree() biasa, sementara CPU lain masih membacanya. Inilah use-after-free.

Diagram race condition CVE-2026-98432: CPU 0 menyerahkan opsi IPv4 ke socket anak tanpa disalin lalu membebaskannya dengan kfree, sementara CPU 1 masih membaca opsi yang sama saat membangun SYNACK

Menurut catatan penilaian tim CVE kernel, dampaknya bisa tiga macam:

  • Kebocoran memori kernel. Data basi bisa ikut terkirim di balasan SYNACK ke penyerang.
  • Korupsi memori. Penulisan di luar batas di memori kernel yang berpotensi membajak alur eksekusi.
  • Kernel crash (denial of service).

Pola ini muncul sejak commit yang membuat request socket diproses tanpa memegang kunci listener, yang masuk di Linux 4.4. Perbaikannya kecil: memori opsi baru dibebaskan setelah semua CPU selesai membacanya (kfree_rcu()). Jalur IPv6 tidak terdampak karena kernel menyalin opsinya. Ada juga jalur sekunder lewat migrasi request socket, tetapi jalur itu hanya aktif bila net.ipv4.tcp_migrate_req=1, yang secara default mati.

Kenapa disebut berbahaya padahal skornya beda-beda?

Celah ini dilaporkan oleh Xinyang Ge dari Anthropic. Pada 27 Oktober, Anthropic menerbitkan riset yang menyebut model AI internalnya berhasil membuat exploit jarak jauh tanpa interaksi (zero-click) yang menghasilkan eksekusi perintah sebagai root di server yang memiliki listener Multipath TCP (MPTCP).

Exploit itu bekerja dua tahap. Pertama, race dipakai untuk membocorkan alamat kernel agar proteksi KASLR bisa dilewati. Kedua, celah yang sama dipakai untuk menimpa sebuah callback pointer sehingga perintah penyerang dijalankan sebagai root. Race yang gagal hanya membatalkan satu percobaan koneksi tanpa membuat sistem crash, jadi penyerang bisa terus mencoba. Dalam uji Anthropic, tahap pertama butuh 48 menit dan tahap kedua 5 menit. Kode exploit, versi kernel, dan konfigurasi uji tidak dipublikasikan.

Perbedaan skor antarvendor berasal dari dua asumsi:

PenilaiSkorAlasan utama
Tim CVE kernel, Ubuntu9.8Kedua sisi race bisa dipicu penyerang, jadi kompleksitas serangan dinilai rendah
SUSE, Oracle, advisory Red Hat8.1Dampak sama tinggi, tetapi memenangkan race antar-CPU dinilai sulit
Amazon Linux7.0Penilaian lebih konservatif
Halaman CVE Red Hat5.9Menganggap dampak praktis terburuk hanya crash

Karena sudah ada demonstrasi exploit root yang kredibel, perlakukan celah ini sebagai eksekusi kode jarak jauh, berapa pun angka yang muncul di scanner Anda.

Distro mana yang sudah punya patch?

Status di bawah dirangkum dari halaman resmi tiap vendor per 29-31 Oktober 2026. Status ini bisa berubah setiap hari, jadi cek ulang tautan vendor di bagian Sumber.

Status patch CVE-2026-98432 per distro per 31 Oktober 2026: Ubuntu, RHEL, Rocky, AlmaLinux, dan Amazon Linux 2 belum ada patch; Debian, Oracle Linux UEK, SUSE, dan Amazon Linux 2023 kernel6.x sudah ditambal; RHEL 7 dan CloudLinux 7 tidak terdampak

DistribusiStatusKernel/advisory perbaikan
Ubuntu 22.04, 24.04, 26.04 LTS, 26.10Rentan, perbaikan sedang dikerjakanBelum dirilis
Ubuntu 16.04, 18.04, 20.04RentanBelum ada
RHEL 8, 9, 10 dan OpenShift 4TerdampakBelum dirilis, tanpa tanggal
Rocky Linux, AlmaLinuxMengikuti RHELMenunggu RHEL
RHEL 7Tidak terdampak-
Debian 13 (trixie)Sudah ditamballinux 6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm)Sudah ditamballinux 6.1.190-1 (DLA-4841-1)
Oracle Linux 7-10 (UEK)Sudah ditambalELSA-2026-500397, -500398, -500399
SUSE / openSUSESebagian sudah ditambalSLES 16.0, 15 SP4-SP6 LTSS sudah; SLES 15 SP7 masih proses
Amazon Linux 2023SebagianPaket kernel6.18 dan kernel6.12 sudah; kernel default dan Amazon Linux 2 belum
CloudLinux 7 (kernel 3.10)Tidak terdampak-
CloudLinux 8TerdampakKernel dan livepatch sedang disiapkan

Satu catatan penting untuk pengguna Ubuntu: angka versi yang tercantum di halaman Ubuntu (misalnya 6.8.0-149.149 untuk 24.04 dan 5.15.0-203.213 untuk 22.04) adalah versi yang sedang dikerjakan, bukan paket yang sudah bisa dipasang. Selama statusnya belum "Released", apt upgrade belum memberi kernel yang aman.

Bagaimana cara mengecek server saya?

1. Apakah kernel yang sedang berjalan sudah ditambal?

Distro besar melakukan backport, jadi nomor versi kernel tidak bisa langsung dibandingkan dengan daftar versi upstream. Cara yang lebih akurat adalah mencari ID CVE di changelog kernel yang sedang berjalan.

# Kernel yang sedang berjalan
uname -r

# Ubuntu / Debian
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -c CVE-2026-98432

# RHEL / Rocky / AlmaLinux / Oracle / Amazon Linux
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

# SUSE
rpm -q --changelog kernel-default | grep -c CVE-2026-98432

Angka di atas 0 berarti kernel tersebut memuat perbaikan. Di Ubuntu dan RHEL hasilnya masih 0 untuk saat ini.

Ingat juga bahwa kernel baru yang sudah terpasang tidak berarti apa-apa sebelum server di-reboot, kecuali Anda memakai livepatch yang khusus mencakup CVE ini.

# Ubuntu / Debian: ada kernel baru yang menunggu reboot?
[ -f /var/run/reboot-required ] && echo "Perlu reboot"

# RHEL dan turunannya
needs-restarting -r

2. Apakah ada layanan yang mendengarkan dengan MPTCP?

Exploit Anthropic menargetkan server dengan listener MPTCP, dan jumlahnya mungkin lebih banyak dari dugaan Anda. Sejak Go 1.24, program Go di Linux secara default membuka listener dengan MPTCP bila kernel mengizinkan, dan Ubuntu 26.04 dilaporkan mengaktifkan MPTCP secara default.

# Daftar listener MPTCP beserta prosesnya
sudo ss -lnMp

# Apakah MPTCP aktif di kernel? (1 = aktif)
sysctl net.mptcp.enabled

Kalau perintah pertama tidak menampilkan apa-apa, berarti tidak ada layanan yang mendengarkan dengan MPTCP. Tetapi itu bukan berarti server aman: celahnya ada di jalur TCP IPv4 biasa, dan belum ada yang memastikan server tanpa MPTCP tidak bisa dibobol dengan cara serupa.

3. Apakah jalur migrasi request socket mati?

sysctl net.ipv4.tcp_migrate_req   # harus 0 (default)

Mitigasi sementara selama patch belum ada

Red Hat menyatakan belum ada mitigasi yang memenuhi standarnya, dan tidak ada vendor yang secara resmi merekomendasikan langkah di bawah ini. Anggap semuanya sebagai lapisan pertahanan tambahan, bukan pengganti kernel yang ditambal, dan uji dulu di server non-produksi.

Blokir paket TCP IPv4 yang membawa IP options

Celah dipicu oleh SYN yang membawa opsi IPv4 Record Route atau Timestamp. Lalu lintas normal hampir tidak pernah membawa IP options, dan RFC 7126 bahkan menyarankan router dan firewall membuang paket dengan opsi tersebut. Header IPv4 tanpa opsi selalu 20 byte (nilai hdrlength 5), jadi aturan nftables berikut hanya menangkap paket yang membawa opsi:

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

# Cek aturan aktif dan berapa paket yang sudah dibuang
sudo nft list table ip cve_2026_98432

Aturan ini hanya membuang paket, jadi tidak membuka port apa pun, dan bisa berjalan berdampingan dengan ufw maupun firewalld. Penulis aturan ini menguji bahwa SYN dengan Record Route memang terbuang sementara koneksi biasa tetap jalan, tetapi tidak menguji terhadap exploit sungguhan. Beberapa catatan:

  • Jangan pasang di jaringan berlabel yang memakai CIPSO (SELinux/Smack NetLabel), karena di sana IP options dipakai secara normal.
  • Kalau server juga merutekan lalu lintas untuk mesin lain, paket TCP ber-IP options yang lewat juga akan terbuang.
  • Aturan yang dibuat dengan perintah di atas hilang setelah reboot.

Agar bertahan setelah reboot tanpa mengganggu aturan ufw atau firewalld, simpan aturan di file terpisah dan muat lewat unit systemd sendiri. Jangan menambahkannya ke /etc/nftables.conf bawaan Debian/Ubuntu, karena file itu diawali flush ruleset yang akan menghapus aturan firewall lain saat dimuat.

sudo tee /etc/nftables-cve-2026-98432.nft >/dev/null <<'EOF'
table ip cve_2026_98432
flush table ip cve_2026_98432
table ip cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    meta l4proto tcp ip hdrlength gt 5 counter drop
  }
}
EOF

sudo tee /etc/systemd/system/cve-2026-98432.service >/dev/null <<'EOF'
[Unit]
Description=Mitigasi sementara CVE-2026-98432 (drop TCP IPv4 ber-IP options)
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/nft -f /etc/nftables-cve-2026-98432.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cve-2026-98432.service

Di RHEL dan turunannya, tulis file langsung di /etc seperti contoh di atas. Memindahkan file dari /tmp dengan mv membawa label SELinux yang salah sehingga nftables gagal membacanya saat boot. Setelah kernel perbaikan terpasang dan server di-reboot, matikan unit ini dan hapus tabelnya.

Kurangi listener MPTCP

  • Program Go: tim keamanan Go menyarankan variabel lingkungan GODEBUG=multipathtcp=0, atau godebug multipathtcp=0 di go.mod bila Anda membangun sendiri. Kode yang memanggil SetMultipathTCP secara eksplisit akan mengabaikan pengaturan ini.
  • Seluruh sistem: sudo sysctl -w net.mptcp.enabled=0 mencegah pembuatan socket MPTCP baru, tetapi listener yang sudah terbuka tetap MPTCP. Restart setiap layanan yang muncul di ss -lnMp, lalu jalankan perintah itu lagi sampai hasilnya kosong. Simpan di /etc/sysctl.d/ agar bertahan setelah reboot.

Tim Go sendiri menyebut mematikan MPTCP per program sebagai mitigasi yang rapuh: satu listener yang terlewat sudah cukup, dan bug dasarnya tidak khusus MPTCP. Jadi langkah ini mengurangi paparan, bukan menutupnya.

Pantau tanda crash

Percobaan exploit yang gagal atau kasar bisa memicu kernel oops. Cari nama fungsi yang terkait celah ini di log kernel:

journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic'

Checklist untuk hari ini

  1. Inventaris kernel: distro, varian kernel (generic, -aws, -azure, -gcp, UEK, dan lainnya), dan versi yang sedang berjalan di setiap server.
  2. Patch dan reboot di distro yang sudah punya perbaikan: Debian, Oracle Linux UEK, SUSE, dan paket kernel6.x Amazon Linux 2023.
  3. Prioritaskan server yang terekspos internet dengan port TCP terbuka lewat IPv4, terutama yang menjalankan layanan Go atau listener MPTCP.
  4. Di Ubuntu dan RHEL, pasang aturan nftables, kurangi listener MPTCP, dan pastikan tcp_migrate_req tetap 0.
  5. Pantau halaman CVE Ubuntu dan Red Hat. Begitu status berubah menjadi Released atau Fixed, pasang kernelnya, reboot, lalu cek ulang changelog kernel yang berjalan.

Pertanyaan yang sering diajukan

Apakah server Ubuntu 24.04 saya rentan?

Ya. Per update terakhir halaman Ubuntu pada 29 Oktober 2026, kernel linux untuk 24.04 masih berstatus rentan dengan perbaikan sedang dikerjakan. Hal yang sama berlaku untuk 22.04, 26.04, dan 26.10, serta varian kernel cloud seperti linux-aws, linux-azure, dan linux-gcp.

Saya pakai shared hosting atau VPS terkelola. Apa yang perlu dilakukan?

Kernel dikelola penyedia, jadi tanyakan status mereka. Beberapa penyedia hosting sudah memasang livepatch tanpa reboot, misalnya SiteGround, sementara CloudLinux masih menyiapkan kernel dan livepatch untuk CloudLinux 8. Kalau Anda punya akses root di VPS, langkah cek dan mitigasi di atas tetap berlaku.

Apakah IPv6 aman?

Jalur utama celah ini hanya ada di IPv4, karena kernel menyalin opsi pada koneksi IPv6. Ada varian IPv6 terbatas pada jalur migrasi dengan opsi CALIPSO, yang akan diperbaiki terpisah.

Apakah sudah dieksploitasi di dunia nyata?

Belum ada vendor atau CERT yang melaporkan serangan nyata, dan celah ini belum masuk katalog CISA KEV. Namun exploit root sudah didemonstrasikan, dan detail teknis celahnya sudah publik. Jangan menunggu laporan serangan untuk bertindak.

Apakah container ikut terdampak?

Container memakai kernel host, jadi yang perlu ditambal adalah kernel di node atau host-nya. Ini juga berlaku untuk node Kubernetes dan OpenShift 4.

Bolehkah saya cherry-pick patch-nya sendiri?

Tim CVE kernel dan Ubuntu sama-sama menyarankan untuk tidak cherry-pick satu perbaikan. Kalau Anda membangun kernel sendiri, gunakan rilis stabil terbaru di cabang Anda (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, atau 7.3).

Sumber

Topik:

Tentang penulis

Tim APIPedia — Tim Engineering APIPedia

Tim engineering di balik APIPedia yang membangun dan memelihara API data Indonesia - ongkir, OCR KTP, data wilayah, BMKG, hingga server MCP - dan menulis panduan integrasinya dari pengalaman langsung.