Dirty Frag: Kerentanan Eskalasi Privilege Zero-Copy Baru di Kernel Linux

Dirty Frag: Rantai kerentanan pada jalur zero-copy kernel Linux yang meracuni page cache, merantai kerentanan xfrm-ESP dan RxRPC. Ini mempengaruhi hampir semua distribusi mainstream sejak 2017 dan memungkinkan eskalasi privilege ke root tanpa password.

Ini Lagi

Sejujurnya, saya tidak pernah berpikir akan menulis posting kernel privilege escalation lagi begitu cepat.

Baru delapan hari sejak artikel Copy Fail. Delapan hari! Blacklist algif_aead dari Copy Fail baru saja diketik di terminal, patch-nya bahkan belum hangat, lalu—Dirty Frag muncul.

Yang lebih absurd, mitigasi Copy Fail sama sekali tidak efektif melawan Dirty Frag. Kali ini, serangan menargetkan subsistem kernel yang berbeda—jalur enkripsi xfrm-ESP dan RxRPC—jadi menonaktifkan algif_aead atau tidak tidak ada bedanya.

Dirty Pipe (2022), Copy Fail (2026.04), Dirty Frag (2026.05)… Setiap kali “mempengaruhi hampir semua distribusi sejak 2017.” Anda tahu artinya? Hampir satu dekade terakhir, siapa pun yang login ke akun tidak terprivilege di sistem Anda punya kesempatan untuk diam-diam menjadi root.

Tapi kalau dipikir, apa ini sepenuhnya salah pengembang kernel? Belum tentu.

Pertumbuhan eksplosif alat auditing kode berbantuan AI dalam beberapa tahun terakhir memungkinkan peneliti keamanan memindai kerentanan yang bersembunyi hampir satu dekade dalam hitungan jam. Bug yang sebelumnya perlu review baris per baris manual kini ditemukan dalam batch oleh AI. Copy Fail ditemukan oleh alat AI Xint Code dalam satu jam. Meskipun Dirty Frag berasal dari auditing manual oleh peneliti Korea Hyunwoo Kim, jalur kode yang dieksploitasi termasuk dalam keluarga yang sama dengan Copy Fail—penulisan page cache pada jalur zero-copy—menunjukkan bahwa jenis cacat desain ini jauh dari kasus terisolasi.

Yang lebih mengganggu adalah proses pengungkapan kali ini. Peneliti awalnya mengirim detail kerentanan ke tim keamanan kernel dengan embargo 5 hari yang disepakati untuk memberi waktu distribusi menambal. Tapi di hari yang sama, pihak ketiga yang tidak terkait langsung mempublikasikan detail lengkap dan exploit untuk kerentanan ESP(xfrm). Tanpa CVE, tanpa patch, tapi PoC tersedia untuk semua orang. Ini bukan pengungkapan bertanggung jawab—ini menusuk punggung setiap pengguna Linux. Jendela penambalan hancur, dan semua orang dipaksa berlari telanjang.

Baik, cukup curhat. Mari kita lihat serius apa kerentanan ini.

Timeline

Analisis Dampak

Perbandingan dengan kerentanan LPE kernel historis:

Distribusi terkonfirmasi terkena:

Dari 6.12 ke 7.0, dari Ubuntu ke Arch—cakupan platform penuh. Ya, hampir semua distribusi mainstream yang Anda instal kemungkinan terkena.

Prinsip Teknis: Kenapa “Dirty Frag”?

Intinya dalam Satu Kalimat

splice() menanamkan referensi page cache file read-only ke dalam frag slot send buffer jaringan (skb) → kernel penerima melakukan operasi kriptografi in-place pada frag (in-place crypto, src == dst mengarah ke memori yang sama) → yang seharusnya operasi dekripsi pada ciphertext menjadi primitif STORE langsung yang menulis ke page cache read-only → mengganti kode mesin su dengan ELF root-shell.

“Dirty” mengacu pada pencemaran page cache, “Frag” mengacu pada eksploitasi mekanisme skb (socket buffer) fragment. Bersama—Dirty Frag.

Pencemaran skb Frag Zero-Copy Path

Bagian ini kunci untuk memahami seluruh kerentanan.

Normalnya, saat Anda menulis data ke socket, kernel menyalin data dari userspace ke skb-nya. Tapi splice() mengambil jalur zero-copy — langsung memasukkan pointer ke halaman page cache file (page struct + offset) ke array frag skb tanpa menyalin data itu sendiri:

struct skb_shared_info {
    struct sk_buff  *frag_list;      // frag linked list
    skb_frag_t      frags[MAX_SKB_FRAGS];  // frag array, masing-masing {page, offset, size}
    // ...
};

Poin kuncinya: page yang diteruskan ke splice() adalah halaman page cache in-memory file Anda (mis. /usr/bin/su) — Anda hanya punya izin baca, tapi referensi ke halaman ini sudah dimasukkan ke skb stack protokol jaringan.

Selanjutnya tergantung apakah stack protokol jaringan penerima “gatal tangan” dan menulis ke halaman ini.

Kerentanan 1: xfrm-ESP Page-Cache Write

Kerentanan pertama ada di jalur dekripsi IPsec ESP.

Fungsi esp_input() digunakan untuk mendekripsi data ciphertext. Normalnya, jika region data skb akan dibagikan dengan frag, kernel harus memanggil skb_cow_data() (Copy-on-Write) untuk menyalin halaman yang dibagikan sebelum beroperasi. Namun, ada jalur kode di esp_input() yang melewati COW:

static int esp_input(struct xfrm_state *x, struct sk_buff *skb)
{
    if (!skb_cloned(skb)) {
        if (!skb_is_nonlinear(skb)) {
            // [1] Linear skb: hanya head data, tanpa frag, aman
            nfrags = 1;
            goto skip_cow;
        } else if (!skb_has_frag_list(skb)) {
            // [2] Ada frag, tapi tanpa frag_list → langsung lewati cow!
            nfrags = skb_shinfo(skb)->nr_frags;
            nfrags++;
            goto skip_cow;  // Bomnya di sini
        }
    }
    // Jalur normal: salin data, aman
    err = skb_cow_data(skb, 0, &trailer);
}

Ketika skb nonlinear (punya frag yang memegang page cache yang diteruskan oleh splice) tapi frag_list kosong, kode langsung melompat ke skip_cow. Kemudian, crypto_authenc_esn_decrypt() melakukan dekripsi AEAD in-place — src dan dst menunjuk ke scatterlist yang sama, yaitu halaman page cache yang ditanam oleh penyerang.

Selama proses dekripsi, ada satu baris kode yang sangat kritis:

// Pindahkan 4 byte tinggi sequence number ke akhir dst SGL
scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);

Baris ini menulis 4 byte ke dst (halaman page cache su Anda) di offset assoclen + cryptlen. Nilai tmp + 1 berasal dari 32 bit tinggi ESP header sequence number — sesuatu yang sepenuhnya dikendalikan penyerang melalui XFRMA_REPLAY_ESN_VAL.seq_hi saat mendaftarkan XFRM SA.

Jadi penyerang mengendalikan secara simultan:

• Ke mana menulis (file offset, diposisikan dengan menyesuaikan panjang payload)
• Nilai apa yang ditulis (4 byte, ditentukan via seq_hi)

Dengan mendaftarkan 48 XFRM SA berbeda, masing-masing dengan seq_hi menyimpan satu fragmen 4-byte ELF, dan mengulang 48 kali, ELF root-shell lengkap dirakit ke page cache su.

Namun, kerentanan ini punya satu keterbatasan: mendaftarkan XFRM SA membutuhkan CAP_NET_ADMIN. Penyerang bisa mendapatkannya dengan membuat user namespace (unshare(CLONE_NEWUSER | CLONE_NEWNET))—tapi AppArmor Ubuntu kebetulan mencegah pengguna tidak terprivilege membuat network namespace.

Karena itu kerentanan kedua diperlukan.

Kerentanan 2: RxRPC Page-Cache Write

Kerentanan kedua ada di jalur dekripsi autentikasi Kerberos protokol RxRPC.

Fungsi rxkad_verify_packet_1() melakukan dekripsi pcbc(fcrypt) in-place pada 8 byte pertama paket data yang diterima:

skcipher_request_set_crypt(req, sg, sg, 8, iv.x);
//                               ^^  ^^
//                             src==dst → operasi in-place!
ret = crypto_skcipher_decrypt(req);  // Penulisan 8-byte terjadi di sini

skb_to_sgvec() langsung mengonversi frag skb (yang berisi halaman page cache yang disambungkan oleh penyerang) menjadi scatterlist, dengan src dan dst menjadi sg yang sama. Jadi operasi dekripsi langsung menulis “hasil dekripsi” 8-byte kembali ke halaman page cache read-only itu.

Dibandingkan dengan xfrm-ESP:

Nilai yang ditulis melalui jalur RxRPC tidak bisa langsung dikontrol—mereka hasil dari fcrypt_decrypt(C, K). Penyerang perlu mendaftarkan kunci K via add_key("rxrpc", ...), lalu brute-force di userspace untuk menemukan K yang menghasilkan plaintext 8-byte target. Untungnya, fcrypt adalah cipher blok 56-bit, 8-byte yang didedikasikan untuk Andrew File System, jadi brute-force bukan masalah besar.

Poin paling kritis: jalur RxRPC sama sekali tidak membutuhkan privilege. Tidak perlu membuat user namespace, tidak perlu network namespace, tidak perlu CAP_NET_ADMIN. Dan Ubuntu memuat modul rxrpc.ko secara default.

Logika Rantai

Kedua kerentanan saling melengkapi:

Inilah yang membuat Dirty Frag mengerikan—tidak peduli bagaimana konfigurasi Anda, selalu ada jalan ke root.

Analisis PoC

Eksploit penuh dirilis di github.com/V4bel/dirtyfrag. Kompilasi dan menjalankan hanya butuh satu baris:

git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Ide intinya tidak rumit:

1. Siapkan ELF minimal 192-byte — root-shell yang dieksekusi dengan eskalasi privilege
2. Bagi 192 byte ini menjadi 48 chunk 4-byte (jika menggunakan jalur xfrm-ESP)
3. Daftarkan satu XFRM SA untuk setiap chunk 4-byte, dengan seq_hi diatur ke nilai chunk tersebut
4. Setiap kali, gunakan splice() untuk mengirim page cache su ke skb, memicu satu penulisan in-place
5. Ulangi 48 kali, region page cache su (192 byte pertama) sepenuhnya diganti dengan ELF root-shell
6. execve("/usr/bin/su") → root shell

Seluruh proses tidak pernah menyentuh file disk. /usr/bin/su di disk tetap tidak tersentuh, md5-nya masih md5 asli. Tapi di page cache kernel, ia telah diam-diam diganti.

Saat proses apa pun menjalankan execve pada su, kernel membaca dari page cache—ups, ia menjalankan binary yang Anda injeksi. Dapat root.

Respons Darurat: Nonaktifkan Sementara Modul Rentan

Per 8 Mei 2026, patch kernel resmi belum dirilis. Sampai patch tersedia, satu-satunya mitigasi sementara adalah membongkar dan melakukan blacklist tiga modul rentan.

Konfirmasi dulu apakah sistem Anda terkena:

lsmod | grep -E 'esp4|esp6|rxrpc'

Jika ada output, Anda terkena.

Jalankan perintah berikut segera (tanpa perlu reboot):

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

Verifikasi:

lsmod | grep -E 'esp4|esp6|rxrpc'

Penting: Jika Anda curiga PoC sudah dieksekusi, bersihkan page cache:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Jika tidak dilakukan, bahkan setelah menonaktifkan modul, page cache yang tercemar tetap di memori—menjalankan su masih memberi root shell.

Efek samping:

• Menonaktifkan esp4/esp6 akan mengganggu tunnel IPsec VPN. Pengguna desktop dan sebagian besar server tidak terpengaruh, tapi jika Anda mengandalkan IPsec VPN (seperti strongSwan, Libreswan), evaluasi dulu dampaknya.
• Menonaktifkan rxrpc dampaknya minimal kecuali Anda menggunakan AFS.

Perlombaan Senjata Kerentanan Berbantuan AI

Pengungkapan Dirty Frag memaksa kita berpikir tentang pertanyaan yang lebih dalam: Kenapa kerentanan LPE kernel bermunculan satu demi satu akhir-akhir ini?

Kerentanan LPE kernel naik dari satu per tahun menjadi satu per bulan, dan sekarang dari satu per bulan menjadi… satu per minggu?

Di balik ini adalah pertumbuhan eksplosif alat auditing kode berbantuan AI. Sebelumnya, mengandalkan review baris per baris manusia, kerentanan yang tidak ditemukan selama sepuluh tahun adalah normal. Sekarang AI bisa memindai seluruh subsistem dalam hitungan jam, menarik semua jalur zero-copy potensial, operasi in-place, dan referensi bersama.

Yang lebih mengkhawatirkan adalah perubahan ekosistem pengungkapan. Embargo Dirty Frag sengaja dilanggar oleh pihak ketiga, dengan detail kerentanan dan PoC dirilis di hari yang sama. Artinya? Dari peneliti melaporkan kerentanan ke security@kernel.org hingga peretas di seluruh dunia mendapat senjata, hanya delapan hari berlalu. Jendela penambalan—hilang.

Kita bisa menyalahkan orang yang melanggar embargo sebagai tidak etis. Tapi kenyataannya, ini akan semakin sering terjadi. AI membuat menemukan kerentanan lebih cepat, dan pembuatan senjata juga lebih cepat. Anda tidak bisa selalu mengandalkan semua orang mematuhi perjanjian embargo.

Dan jangan lupa, keluarga kerentanan yang sama masih terus digali:

Prinsip inti keempat kerentanan ini sangat mirip—splice() memasukkan referensi page cache read-only ke subsistem kernel, dan subsistem menulis in-place pada frag. Yang mereka ungkap sebenarnya kelas masalah desain yang sama:

Setiap desain, jika dilihat sendiri, adalah optimasi kinerja atau persyaratan fungsional yang masuk akal. Tapi dirangkai, mereka membentuk rantai kerentanan di mana pengguna lokal mana pun bisa menjadi root tanpa password.

Kecuali upstream kernel memeriksa ulang secara menyeluruh paradigma “operasi in-place pada jalur zero-copy,” saya jamin—ini bukan yang terakhir.

Untuk pengguna biasa, saran saya sederhana:

1. Jalankan perintah blacklist di atas sekarang juga. Kembalikan ketika patch resmi tiba.
2. Pantau pembaruan kernel dari package manager Anda. Setelah versi yang diperbaiki tersedia, upgrade dan reboot segera.
3. Secara rutin lsmod | grep untuk periksa apakah modul ini tidak sengaja dimuat.

Referensi

• GitHub PoC Repository: https://github.com/V4bel/dirtyfrag
• Laporan LWN: https://lwn.net/Articles/1071719/
• Laporan Phoronix: https://www.phoronix.com/news/Dirty-Frag-Linux
• Analisis Teknis Korea (GeekNews): https://news.hada.io/topic?id=29275
• Situs Pengungkapan Copy Fail: https://copy.fail/
• Copy Fail 2: https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo

Infografis

Gambar 1: Gambaran kerentanan Dirty Frag — bagaimana referensi page cache zero-copy dieksploitasi melalui skb frags