CVE-2026-72018: Out-of-Bounds Write di SMC-D Loopback Linux dan Jalan ke Root

Sebuah kerentanan baru di kernel Linux, dilacak sebagai CVE-2026-72018, menunjukkan bagaimana sebuah primitif korupsi memori yang sangat terbatas pun bisa berujung pada akses root. Bug ini berada di implementasi loopback DIBS yang dipakai oleh subsistem Shared Memory Communications Direct (SMC-D). Tingkat keparahannya dinilai tinggi dengan skor CVSS 3.1 sebesar 7.8, dan penyerang lokal yang sudah memiliki kemampuan CAP_NET_ADMIN bisa meningkatkan hak aksesnya menjadi root.

Yang membuat kasus ini menarik bukan ukuran kerusakan yang bisa ditimbulkan, melainkan di mana kerusakan itu akhirnya mendarat. Peneliti tidak mendapat kendali penuh atas memori kernel seperti pada eksploitasi arbitrary write konvensional. Yang mereka dapatkan hanyalah penulisan nol sepanjang 16 byte pada lokasi yang hanya sebagian bisa dikendalikan. Namun dengan penataan memori kernel yang cermat, primitif terbatas itu cukup untuk menyentuh struktur kredensial proses dan membuat proses yang terdampak tampak sebagai root di mata kernel.

Akar Masalah di Driver DIBS Loopback

Sumber masalahnya adalah ketiadaan pemeriksaan batas di rutin move_data() pada driver dibs_loopback. Kode tersebut memakai memcpy() untuk memindahkan data ke sebuah Direct Memory Buffer (DMB), tetapi tidak memverifikasi bahwa offset dan panjang penulisan yang diminta tetap berada di dalam buffer yang dialokasikan. Akibatnya, nilai yang dipengaruhi penyerang bisa membuat kernel menulis melewati alokasi DMB yang seharusnya hanya 16 KB.

Kesalahan seperti ini termasuk kelas yang klasik: operasi penyalinan memori yang mengasumsikan input sudah tervalidasi, padahal jalur masuknya bisa dikendalikan dari luar. Dalam kasus ini, jalur masuk itu adalah handshake jaringan, bukan antarmuka pengguna langsung, sehingga sulit terdeteksi oleh pengujian fungsional biasa.

Kenapa SMC-D Jadi Relevan di Sistem Biasa

SMC adalah protokol rancangan IBM yang bertujuan mengurangi overhead penyalinan data pada komunikasi berthroughput tinggi. Ada dua varian: SMC-R yang bergantung pada perangkat keras berkemampuan RDMA, dan SMC-D yang memakai memori bersama. Secara historis, SMC-D sangat terkait dengan sistem IBM Z dan perangkat keras ISM khusus, sehingga kode ini jarang tersentuh di sistem umum.

Keadaan berubah dengan hadirnya transport virtual dibs_loopback. Transport ini membuat sebagian kode SMC-D dapat diakses pada sistem Linux konvensional, termasuk lingkungan x86 tanpa perangkat keras khusus. Efeknya langsung terasa pada relevansi keamanan: kode yang tadinya hanya berjalan di lingkungan sempit kini punya jalur yang bisa dijangkau di sistem yang jauh lebih luas. Inilah pola yang patut diwaspadai secara umum, yaitu ketika sebuah subsistem yang dulunya bergantung perangkat keras mendapat implementasi virtual, permukaan serangannya ikut melebar.

Bagaimana Rantai Eksploitasinya Bekerja

Menurut peneliti di XBOW, rantai eksploitasi dimulai dari kolom yang dikendalikan penyerang di handshake SMC Connection Layer Control (CLC). Nilai seperti dmbe_idx dan dmbe_size memengaruhi perhitungan yang dipakai untuk menentukan offset transmisi. Sebuah token DMB lalu menunjuk buffer tujuan. Offset yang dihasilkan akhirnya masuk ke implementasi loopback DIBS, tempat pemeriksaan batas yang hilang memungkinkan memcpy() beroperasi melewati DMB yang dialokasikan.

Perhatikan bahwa rantai ini melintasi beberapa komponen kernel sebelum mencapai primitif korupsi memorinya: kemampuan jaringan, penyaringan paket, negosiasi SMC-D, transport virtual, dan manajemen memori kernel. Kerumitan itu justru yang membuat bug semacam ini sulit ditemukan lewat pengujian permukaan. Setiap langkah tampak wajar jika dilihat sendiri-sendiri, dan masalahnya baru muncul ketika semuanya dirangkai.

Primitif yang Terbatas tapi Bermakna

Eksploitasi CVE-2026-72018 tidak langsung memberi penyerang kemampuan arbitrary kernel write yang terkendali penuh. Yang diperoleh peneliti adalah primitif yang jauh lebih terbatas: penulisan nol sepanjang 16 byte yang dapat diprediksi, pada lokasi berkelipatan 16 KB yang hanya sebagian bisa dikendalikan.

Sendiri-sendiri, primitif seperti itu biasanya kurang berguna. Namun peneliti membuktikan bahwa penataan memori kernel yang cermat membuat korupsi terbatas itu menjadi bermakna. Bukti konsepnya menyasar struktur kredensial proses Linux, yang memuat informasi identitas dan hak istimewa yang dipakai kernel. Dengan menata memori kernel sehingga operasi penulisan nol menimpa kolom kredensial yang relevan, termasuk effective UID, peneliti membuat proses yang terdampak tampak sebagai root.

Ini prinsip eksploitasi yang penting: penyerang tidak selalu perlu mengendalikan setiap byte yang dikorupsi jika korupsi itu bisa ditempatkan secara andal pada objek yang sensitif terhadap keamanan. Yang dibutuhkan adalah posisi yang tepat, bukan kendali penuh atas nilai.

CAP_NET_ADMIN: Syarat yang Mempersempit Dampak

CVE-2026-72018 bukan kerentanan peningkatan hak istimewa lokal yang bisa dipakai semua pengguna. Penyerang harus sudah memiliki CAP_NET_ADMIN, sebuah kemampuan Linux yang cukup kuat dan memungkinkan berbagai operasi administrasi jaringan. Peneliti memakai kemampuan itu untuk menginisialisasi lingkungan SMC-D yang diperlukan, lalu mencegat dan memodifikasi trafik CLC loopback melalui aturan NFQUEUE pada nftables.

Syarat ini secara signifikan mengurangi jangkauan kerentanan dibanding bug yang bisa dieksploitasi pengguna lokal tanpa hak istimewa apa pun. Meski demikian, CAP_NET_ADMIN bisa saja tersedia di beban kerja yang berjalan di container, layanan yang menghadap jaringan, dan lingkungan aplikasi berhak istimewa lainnya. Dalam konteks penyebaran Linux modern, prasyarat ini tetap relevan dan tidak bisa diabaikan begitu saja.

Bagi tim yang mengelola Kubernetes atau platform container, ini pengingat untuk memeriksa kapabilitas apa saja yang sebenarnya diberikan ke beban kerja. Banyak aplikasi diberi CAP_NET_ADMIN hanya karena "lebih mudah" saat konfigurasi, padahal kebutuhan aslinya lebih sempit. Mengurangi kapabilitas yang tidak perlu bukan hanya memperkecil dampak satu CVE tertentu, tetapi juga mempersempit seluruh kelas kerentanan kernel lokal.

Hasil Uji dan Versi yang Sudah Diperbaiki

XBOW melaporkan telah mendemonstrasikan eksploitasi terhadap Ubuntu 24.04 yang menjalankan Linux 7.1.0-rc6, dengan mitigasi kernel dinonaktifkan selama pengujian. Bukti konsep diuji pada 100 kali boot terpisah dan berhasil mendapatkan akses root pada 22 kasus. Hasil ini menunjukkan bahwa primitif tersebut tidak deterministik dalam kondisi yang diuji, karena sangat bergantung pada tata letak heap kernel dan kondisi memori. Meski demikian, jalur peningkatan hak istimewa yang praktis tetap terbukti.

Kabar baiknya, kerentanan ini sudah diperbaiki. Rilis pemeliharaan kernel yang diidentifikasi tidak terpengaruh antara lain 6.12.97, 6.18.40, dan 7.1.5. Perbaikannya dilakukan dengan menambahkan validasi yang memastikan offset dan panjang penulisan tidak keluar dari buffer yang dialokasikan, yaitu pemeriksaan batas yang seharusnya sudah ada sejak awal.

Bagi administrator sistem, langkah pertama adalah memastikan kernel yang dipakai sudah berada pada versi yang diperbaiki atau lebih baru. Distribusi biasanya memuat versi kernel spesifik mereka sendiri, jadi membandingkan langsung dengan nomor versi utama belum tentu cukup. Yang lebih aman adalah mengikuti panduan keamanan dari distribusi masing-masing dan menerapkan pembaruan yang mereka rilis untuk CVE ini.

Pelajaran untuk Pertahanan

Ada pelajaran yang lebih luas daripada sekadar menambal satu CVE. Pertama, mengurangi kapabilitas Linux yang berhak istimewa bisa membatasi kegunaan seluruh kelas kerentanan kernel lokal. Menjauhkan CAP_NET_ADMIN dari aplikasi yang tidak benar-benar membutuhkannya memberi lapisan perlindungan tambahan, bahkan terhadap bug yang belum ditemukan.

Kedua, ketika sebuah subsistem yang dulunya bergantung pada perangkat keras tertentu mendapat implementasi virtual atau berbasis perangkat lunak, peneliti keamanan cenderung mulai memeriksa jalur kernel yang tadinya jarang tersentuh. Kode yang dulu hanya berjalan di perangkat khusus kini berjalan di mana-mana, dan asumsi lama tentang "ini tidak relevan untuk kami" perlu ditinjau ulang.

Ketiga, jangan meremehkan primitif yang tampak lemah. Penulisan nol 16 byte terdengar sepele, tetapi dalam kondisi memori yang tepat, itu cukup untuk mengubah identitas efektif sebuah proses. Penilaian risiko sebaiknya tidak hanya melihat seberapa besar kerusakan yang bisa dibuat, tetapi juga seberapa berharga objek yang bisa disentuh.

Langkah Praktis

Untuk tim yang mengelola sistem Linux, urutan yang masuk akal adalah: periksa versi kernel dan status patch terhadap panduan distribusi, terapkan pembaruan bila belum, lalu audit kapabilitas yang diberikan ke container dan layanan. Untuk lingkungan yang menjalankan beban kerja tidak tepercaya, pertimbangkan untuk menonaktifkan modul SMC bila tidak dipakai, sebagai pengurangan permukaan serangan tambahan.

Membandingkan dengan Kelas Kerentanan Kernel Lain

Kerusakan memori di kernel Linux bukan hal baru. Yang membedakan CVE-2026-72018 adalah kombinasi antara primitif yang sangat terbatas dan jalur masuk yang tidak biasa. Banyak kerentanan kernel lokal lain memberi penyerang kendali lebih besar atas memori, tetapi mensyaratkan akses ke antarmuka yang lebih langsung. Di sini, jalur masuknya adalah handshake protokol jaringan, yang berarti penyerang harus lebih dulu berada di posisi yang memungkinkan memengaruhi trafik tersebut.

Pola yang mirip dengan kasus ini adalah kerentanan yang muncul ketika sebuah subsistem dirancang untuk lingkungan terbatas lalu dipakai di lingkungan yang lebih luas. Asumsi desain yang tadinya wajar di perangkat khusus menjadi berbahaya ketika kode yang sama berjalan di sistem umum. Ini alasan mengapa audit keamanan perlu memperhatikan bukan hanya kode yang aktif dipakai, tetapi juga kode yang "tertidur" dan bisa diaktifkan oleh konfigurasi tertentu.

Konsekuensi praktisnya, administrator tidak bisa hanya mengandalkan daftar fitur yang dipakai sehari-hari. Fitur yang tidak pernah kamu sentuh bisa tetap menjadi permukaan serangan jika ia aktif secara default atau mudah diaktifkan. Memahami apa yang berjalan di kernel, dan apa yang bisa diaktifkan, adalah bagian dari menjaga sistem tetap ramping.

Menilai Risiko di Lingkungan Anda

Pertanyaan pertama yang perlu dijawab adalah apakah CAP_NET_ADMIN tersedia untuk proses yang tidak sepenuhnya tepercaya. Kalau jawabannya tidak, paparan terhadap kerentanan ini jauh lebih kecil, meskipun patch tetap perlu diterapkan. Kalau jawabannya ya, misalnya ada layanan jaringan yang berjalan dengan kemampuan itu atau container yang diberi kapabilitas tersebut, prioritasnya naik.

Pertanyaan kedua adalah apakah subsistem SMC aktif di kernel kamu. Pada banyak distribusi, modul ini bisa dimuat, tetapi belum tentu dimuat secara default. Menonaktifkan modul yang tidak dipakai mengurangi permukaan serangan tanpa mengubah fungsionalitas yang kamu butuhkan. Ini langkah murah yang sering diabaikan karena dianggap remeh.

Pertanyaan ketiga menyangkut pemisahan hak akses. Kalau satu proses yang menghadap jaringan berhasil dieksploitasi, seberapa jauh dampaknya bisa menyebar. Isolasi yang baik membatasi kerusakan pada satu proses, sementara isolasi yang longgar membuka jalan ke seluruh sistem. Kerentanan kernel lokal seperti ini menegaskan pentingnya menganggap setiap proses yang menghadap jaringan sebagai batas kepercayaan, bukan sekadar komponen biasa.

Verifikasi dan Deteksi

Setelah patch diterapkan, verifikasi bahwa kernel yang benar-benar berjalan sudah versi yang diperbaiki, bukan hanya paket yang diperbarui di disk. Reboot sering diperlukan untuk kernel, dan sistem yang jarang di-reboot bisa tetap menjalankan kernel lama meski paket sudah diperbarui. Memeriksa versi kernel yang aktif setelah reboot adalah langkah yang mudah terlewat.

Untuk deteksi, perhatikan aktivitas yang tidak biasa pada handshake SMC-D dan penggunaan aturan NFQUEUE yang tidak dikenal. Karena eksploitasi memerlukan kemampuan memodifikasi trafik loopback, jejak konfigurasi jaringan yang aneh bisa menjadi indikator. Ini bukan pengganti patch, tetapi menambah lapisan pengamatan yang berguna untuk lingkungan dengan persyaratan keamanan tinggi.

Terakhir, catat bahwa kerentanan ini menuntut CAP_NET_ADMIN. Lingkungan yang tidak pernah memberikan kemampuan itu ke proses yang tidak tepercaya memiliki profil paparan yang jauh berbeda. Memahami prasyarat seperti ini membantu tim memprioritaskan perbaikan dengan tepat, alih-alih memperlakukan setiap CVE sebagai risiko yang sama besarnya.