GhostLock, UAF Stack yang Ada di Semua Distribusi Linux Selama 15 Tahun

• GhostLock (CVE-2026-43499) adalah kerentanan kernel yang diperkenalkan di Linux 2.6.39 dan diperbaiki di 7.1; penyerang lokal tanpa hak istimewa dapat memicu stack UAF hanya dengan system call threading umum, lalu memanfaatkannya untuk mendapatkan hak akses root dan keluar dari kontainer
• remove_waiter() pada jalur proxy Requeue-PI menghapus pi_blocked_on milik current, bukan task yang benar-benar menunggu, sehingga pada task yang kembali ke user space tersisa pointer yang mengarah ke stack frame yang sudah dibebaskan
• Dengan tiga futex dan tiga thread, penyerang membuat siklus dependensi PI untuk memicu rollback -EDEADLK, lalu menyusun rt_mutex_waiter palsu pada buffer stack yang dapat dikendalikan milik PR_SET_MM_MAP untuk memperoleh penulisan pointer terbatas
• Eksploit mencari alamat dasar KASLR dan physmap dengan prefetch, menempatkan struktur palsu dan stack ROP di CPU entry area (CEA), lalu menimpa inet6_protos[IPPROTO_UDP] untuk membajak alur kontrol lewat paket loopback UDP IPv6
• Para peneliti menerima $92.337 dari Google kernelCTF untuk eksploit eskalasi hak akses dan container escape yang stabil 97%, dan semua distribusi Linux yang belum dipatch harus di-upgrade ke LTS terbaru

---

Cakupan dampak dan ringkasan kerentanan

• GhostLock adalah kerentanan kernel Linux yang ditemukan oleh VEGA, dan dapat dipicu oleh pengguna lokal tanpa hak istimewa tanpa hak khusus maupun user namespace
• Kerentanan ini diperkenalkan oleh pengerjaan ulang rtmutex pada 8161239a8bcc, dengan cakupan dampak dari v2.6.39-rc1 hingga v7.1-rc1
• Diperbaiki pada April 2026 di 3bfdc63936dd, dan satu-satunya konfigurasi kernel yang diperlukan adalah CONFIG_FUTEX_PI=y
• Penyerang dapat meningkatkan hak akses melalui proses berikut
  • Mendapatkan dangling kernel pointer yang menunjuk ke memori stack kernel hanya dengan system call threading umum
  • Membuat primitive terbatas yang dapat menulis pointer atau nilai nol 8-byte ke alamat yang hampir arbitrer
  • Membajak tabel fungsi untuk mengambil alih alur kontrol dan memperoleh hak akses root
• Semua distribusi Linux yang belum dipatch terdampak, sehingga harus di-upgrade ke versi LTS terbaru

Penyebab remove_waiter() membersihkan task yang salah

• remove_waiter() di kernel/locking/rtmutex.c awalnya ditulis untuk jalur ketika thread yang diblokir membersihkan sendiri status tunggunya
• Pada slow path normal, current yang sedang berjalan adalah task pemilik waiter, sehingga tindakan menghapus current->pi_blocked_on adalah benar
• Pada jalur proxy Requeue-PI, rt_mutex_start_proxy_lock() memasukkan rt_mutex_waiter ke antrean atas nama task lain yang sedang tidur, lalu melakukan rollback jika terjadi kesalahan
  • Saat itu, current adalah requeuer yang memanggil FUTEX_CMP_REQUEUE_PI
  • Waiter yang sebenarnya adalah task terpisah yang tertidur di FUTEX_WAIT_REQUEUE_PI
• Ketika __rt_mutex_start_proxy_lock() mengembalikan -EDEADLK, remove_waiter() menghapus waiter dari lock tetapi hanya menjadikan current->pi_blocked_on sebagai NULL
• pi_blocked_on milik waiter yang sebenarnya tetap menunjuk ke rt_mutex_waiter di stack kernelnya sendiri, dan ketika waiter kembali ke user space, stack frame tersebut dianggap sudah dibebaskan
• Setelah itu, saat penelusuran rantai PI melewati task tersebut, ia melakukan dereference objek stack yang sudah dibebaskan
• lockdep hanya memeriksa pi_lock mana yang dipegang, bukan lock itu milik siapa, sehingga tidak menangkap kesalahan ini

Siklus tiga futex yang membuat rollback -EDEADLK

• Untuk mencapai jalur error, dibuat siklus dependensi PI dengan tiga futex dan tiga thread
  • f_pi_chain: PI futex yang dikunci lebih dulu oleh waiter
  • f_pi_target: PI futex yang dikunci lebih dulu oleh owner dan menjadi target requeue
  • f_wait: futex biasa tempat waiter menunggu dengan FUTEX_WAIT_REQUEUE_PI
• Urutan pemicunya sebagai berikut
  1. waiter mengunci f_pi_chain, lalu diblokir di FUTEX_WAIT_REQUEUE_PI(f_wait -> f_pi_target), dan rt_mutex_waiter ditempatkan di stack kernelnya sendiri
  2. owner mengunci f_pi_target, lalu diblokir di f_pi_chain yang dipegang oleh waiter
  3. thread main memanggil FUTEX_CMP_REQUEUE_PI(f_wait -> f_pi_target)
• Saat proxy requeue mencoba menghubungkan waiter ke f_pi_target, siklus waiter → f_pi_target → owner → f_pi_chain → waiter tertutup
• Penelusuran rantai PI mengembalikan -EDEADLK dan menjalankan rollback yang salah, sehingga waiter terbangun dengan pi_blocked_on yang menggantung
• Kondisi pentingnya adalah requeuer melakukan rollback ketika waiter masih memiliki objek stack tersebut; setelah siklus terbentuk, proses berjalan dengan sendirinya
• Setelah waiter kembali ke user space, tidak ada lagi tekanan waktu, dan penelusuran rantai dapat dipicu kapan saja nanti dengan sched_setattr()
• Konfigurasi ini memakai tiga thread, tetapi race UAF itu sendiri dapat dipicu bahkan pada satu core CPU

Primitive awal yang diberikan oleh stack UAF

• Pointer yang menggantung menunjuk ke rt_mutex_waiter yang berada di frame FUTEX_WAIT_REQUEUE_PI sebelumnya
• Jika byte yang dapat dikendalikan ditempatkan kembali pada kedalaman stack yang sama dalam task yang sama, kernel dapat dibuat melakukan dereference terhadapnya sebagai rt_mutex_waiter palsu
• Bergantung pada bagaimana struktur palsu ditempatkan, dua primitive utama dapat diperoleh dari satu akses
  • Pointer dapat ditulis ke alamat yang hampir arbitrer dengan kondisi tertentu
  • Nilai nol 8-byte dapat ditulis ke alamat yang hampir arbitrer dengan kondisi tertentu
• Sebelum penulisan, beberapa dereference pointer dan pemeriksaan integritas dilakukan, tetapi jika syaratnya terpenuhi, kernel tetap tidak crash setelah penulisan dan kembali normal
• Untuk menyelesaikan eksploit, semuanya diperlukan: penggunaan ulang stack frame, lolos pemeriksaan struktur waiter palsu, dan pemilihan target yang memenuhi batasan penulisan

Menggunakan kembali frame stack yang dibebaskan dengan PR_SET_MM_MAP

• waiter memanggil prctl(PR_SET_MM, PR_SET_MM_MAP, ...) segera setelah kembali dari system call futex
• prctl_set_mm_map() menyalin auxv yang diberikan pengguna ke buffer stack berukuran tetap unsigned long user_auxv[AT_VECTOR_SIZE]
• Karena buffer ini berada pada kedalaman stack yang mirip dengan waiter yang telah dibebaskan, blok qword besar, selaras, dan dapat dikendalikan akan menimpa di atas rt_mutex_waiter sebelumnya
• Area auxv yang tumpang tindih disusun sebagai berikut
  • tree: dibuat sebagai node rb yang, saat dihapus, menaikkan pointer anak terpilih W0_BASE menjadi root tree
  • task: diatur ke &init_task agar dereference dalam penelusuran chain dapat dilalui dengan aman
  • lock: ditetapkan ke &inet6_protos[IPPROTO_UDP] - 8 untuk menyelaraskan target penulisan
  • wake_state: diatur ke 0
• auxv ditempatkan di memfd dan diatur agar penyalinan melewati batas halaman, lalu thread saudara melakukan race fallocate(PUNCH_HOLE) pada halaman belakang saat prctl berjalan untuk memperpanjang waktu copy_from_user
• Thread consumer di CPU lain memanggil sched_setattr() pada waiter saat waiter palsu masih tersisa di stack untuk menelusuri PI chain
• System call lain yang memakai variabel lokal stack besar dan dapat dikendalikan, seperti clone, setsockopt, pselect, dan keyctl, juga dapat menjalankan peran yang sama
• prctl dipilih karena buffernya besar, selaras, dan tidak memerlukan namespace; kandidat tambahan disertakan dalam kode PoC publik

Membuat penulisan pointer terbatas melalui penghapusan rb-tree

• Mengendalikan waiter palsu tidak langsung menghasilkan arbitrary write penuh; penelusuran chain menjalankan jalur berikut
  • menemukan waiter palsu dari task->pi_blocked_on
  • menemukan rt_mutex_base palsu dari fake waiter->lock
  • rt_mutex_dequeue(lock, waiter) melakukan penghapusan rb-tree dari lock->waiters
• Ini memanfaatkan sifat bahwa saat node root yang hanya memiliki satu anak dihapus, anak tersebut ditulis ke slot root
• Jika lock ditetapkan ke target - 8, data di sekitarnya ditafsirkan sebagai field rt_mutex_base berikut
  • target - 8: wait_lock yang harus terbaca sebagai keadaan tidak terkunci
  • target: waiters.rb_root.rb_node yang akan ditimpa
  • target + 8: waiters.rb_leftmost
  • target + 16: owner
• Akibatnya, satu penulisan yang dieksekusi adalah *(uint64_t *)target = W0_BASE
• Alamat target kira-kira harus memenuhi syarat berikut
  • 32 bit bawah dari target - 0x08 harus bernilai 0
  • nilai 64 bit pada target + 0x08 harus bernilai 0
  • nilai pada pointer owner di target + 0x10, setelah flag bawah dikecualikan, harus bernilai 0
• Jika qword di depan tampak seperti spinlock yang terkunci, trylock gagal dan proses selesai tanpa menulis apa pun
• Jika nilai di belakang menunjuk ke top waiter atau owner yang tidak terkendali, atau ke nilai yang tidak terpetakan, kernel panic dapat terjadi
• Karena W0_BASE harus tetap valid hingga perbandingan, requeue, pembaruan prioritas, dan wakeup tanpa owner selesai, digunakan alias direct-map dari CEA

Kebocoran prefetch dan CPU entry area

• Menemukan alamat dasar KASLR dan physmap

  • Waktu eksekusi prefetch untuk alamat tertentu berbeda tergantung apakah alamat tersebut terpetakan di page table saat ini
  • Jika proses tanpa privilege mengukur waktu eksekusi pada rentang alamat kernel, lokasi pemetaan dapat diperkirakan; prinsip detailnya dijelaskan dalam paper prefetch
  • Karena entropi alamat dasar image kernel Linux default sekitar 9 bit, pengukuran berulang dapat memulihkan alamat dasar KASLR dengan keandalan hampir 100%
  • Secara teori, CPU yang memiliki prefetch dan tidak memiliki KPTI yang memadai terdampak, tetapi dalam praktiknya teknik ini terutama digunakan pada x86 dengan KPTI dimatikan
  • Image kernelCTF mematikan KPTI; bahkan saat KPTI aktif, alamat dasar image kernel dapat dipulihkan melalui trampoline dengan menggabungkan prefetch dan EntryBleed

• Melewati randomisasi alamat CEA

  • CPU entry area(CEA) adalah struktur per-CPU x86 yang menyimpan stack untuk entry/exception handling dan konteks register
  • Ketika program tanpa privilege memicu software exception, konteks registernya sendiri ditulis ke pt_regs pada stack exception CEA, sehingga membuat sekitar 120 byte memori beruntun yang dapat dikendalikan
  • Sebelum Linux 6.2, alamat virtual CEA sepenuhnya tetap, sehingga dapat langsung digunakan untuk struktur palsu, menyerap efek samping dereference pointer, dan menyusun stack ROP
  • Setelah publikasi Bringing back the stack attack dari Project Zero, sejak Linux 6.2 alamat virtual CEA dirandomisasi secara kuat
  • Alamat virtual CEA setiap CPU dirandomisasi secara berbeda, tetapi alamat fisiknya tetap; karena itu, jika alamat dasar physmap diketahui, alias direct-map dapat dihitung
  • Dengan menggabungkan prefetch, normalisasi batas kandidat, dan pemeriksaan halaman CEA yang diperkirakan, alias sekitar dieliminasi dan cea_direct = physmap_base + CPU1_CEA_BASE diperoleh
  • Pada lingkungan boot 3,5GB kernelCTF LTS 6.12.80, offset terkait adalah 0x11c517000(+0x1f58)

Menggunakan kembali CEA sebagai waiter palsu dan objek lanjutan

• Sebelum penulisan pertama, waiter dan lock palsu yang konsisten secara internal ditempatkan pada W0 di CEA
  • task diatur ke &init_task
  • prio diisi dengan nilai yang valid
  • wait_lock pada lock dibuat tampak tidak terkunci
  • owner disusun agar dequeue, requeue, pembaruan prioritas, dan wakeup dapat dilalui dengan aman
• Setelah penulisan rb-tree selesai, W0 tidak lagi harus menjadi waiter, sehingga CEA dapat diisi ulang sebagai struktur yang dibutuhkan oleh target yang ditimpa
• CEA kecil, sekitar 120 byte, tetapi efisien karena data dapat ditempatkan pada alamat kernel tetap yang dapat dihitung
• NPerm dan kernelsnitch, dan lainnya, dapat menjalankan peran yang sama pada ruang yang lebih luas
• Eksploit memanfaatkan satu area CEA secara berurutan atau bersamaan sebagai rt_mutex_waiter palsu, lock palsu, inet6_protocol, slot JOP dan stack pivot, serta stack ROP akhir

Pembajakan alur kontrol melalui inet6_protos[IPPROTO_UDP]

• Pada Linux x86_64 umum, setelah mendapatkan alamat dasar KASLR, penyerang dapat memilih jalur singkat untuk menimpa tabel fungsi yang memenuhi syarat atau objek yang memuatnya
• Area di sekitar inet6_protos[IPPROTO_UDP] pada wilayah data yang dapat ditulisi secara alami memenuhi batasan yang diperlukan
  • inet6_protos[16] == NULL menjadi status tidak terkunci dari wait_lock palsu
  • inet6_protos[17] == &udpv6_protocol adalah target nyata yang akan ditimpa
  • inet6_protos[18] == NULL menjadi rb_leftmost palsu
  • inet6_protos[19] == NULL menjadi owner palsu
• Setelah penulisan selesai, inet6_protos[IPPROTO_UDP] menunjuk ke inet6_protocol palsu di dalam halaman CEA
• CEA disemprot ulang untuk menyusun struktur sebagai berikut
  • handler: ditetapkan sebagai gadget pivot pertama
  • err_handler: tidak digunakan
  • flags: diatur ke INET6_PROTO_NOPOLICY | INET6_PROTO_FINAL
• Dengan mengirim paket loopback UDP IPv6 yang menulis data setelah melakukan connect ke ::1, kernel akan memanggil handler palsu sehingga program counter dapat dikendalikan

Pivot singkat dan eskalasi hak akses DirtyMode

• Pada target lts-6.12.80 Google kernelCTF, karena tidak ditemukan gadget pivot stack tunggal yang sesuai, alamat CEA dimasukkan ke rbp melalui load/call tambahan, lalu pivot dilakukan dengan mov rsp, rbp; pop rbp; ret
• ret2usr atau penimpaan penuh /proc/%P/fd/x membutuhkan sekitar 10 qword gadget, terlalu besar dibandingkan ruang CEA yang terbatas
• Untuk tahap akhir digunakan DirtyMode, yang mengubah bit hak akses dengan satu kali penulisan dan menjalankan sisa proses di ruang pengguna
• Target penulisan adalah coredump_sysctls[1].mode pada data kernel, yaitu mode akses sysctl core_pattern
• Karena berbagi slide KASLR yang sama dengan image kernel, alamatnya dapat dihitung, dan cukup memakai nilai dengan bit tulis, yaitu bit terendah kedua, yang disetel
• Dengan chain singkat pop reg; mov [reg], reg; ret, nilai mode diubah dan thread yang dibajak dihentikan dengan aman menggunakan msleep
• Setelah /proc/sys/kernel/core_pattern dapat ditulis oleh semua pengguna, proses tanpa privilege dapat menulis |/proc/%P/fd/666 %P dan membuat helper crash, sehingga kernel menjalankan biner penyerang dengan hak root
• Penulisan rb-tree awal tidak dapat langsung mencapai coredump_sysctls[1].mode karena batasan penempatan batch, sehingga perubahan mode dilakukan pada tahap ROP singkat

Alur eksploit lengkap dan hasil

• Serangan berjalan dengan urutan berikut
  1. Membocorkan slide image kernel dan alamat dasar physmap dengan prefetch
  2. Dengan GhostLock, meninggalkan rt_mutex_waiter dangling pada pi_blocked_on milik waiter
  3. Menggunakan PR_SET_MM_MAP untuk memakai ulang frame stack kernel yang sama dan membuat waiter palsu
  4. Memanfaatkan penghapusan rtmutex rb-tree untuk menulis pointer CEA ke inet6_protos[IPPROTO_UDP]
  5. Menempatkan inet6_protocol palsu, slot pivot, dan stack ROP di CEA
  6. Memanggil handler yang telah ditimpa melalui paket loopback UDP IPv6
  7. Dengan DirtyMode, mengubah bit mode core_pattern dan menyelesaikan eskalasi hak akses di ruang pengguna
• Di lingkungan jarak jauh kernelCTF, jalur yang menggabungkan CEA dan DirtyMode memperoleh flag dalam sekitar 5 detik
• Eksploit lengkap dipublikasikan di proyek CyberMeowfia
• Pada Android, penggunaan ulang frame stack serta metode bypass ASLR dan CFI berbeda, dan akan dibahas dalam tulisan lanjutan terpisah

Jalur alternatif dan mitigasi

• Ruang ROP yang lebih besar

  • Memori berbasis NPerm dapat digunakan sebagai stack palsu besar setelah alur kontrol dibajak
  • Jalur yang lebih berat seperti kebocoran heap-KASLR oleh Lukas Maar juga memungkinkan, tetapi menambah tahapan sehingga waktu eksekusi meningkat
  • Di kernelCTF, chain paling singkat dan paling andal lebih menguntungkan, sehingga kombinasi CEA dan DirtyMode digunakan

• Patch kernel

  • Patch final mengambil pi_lock dan menghapus pi_blocked_on berdasarkan waiter->task, bukan current
  • remove_waiter() menyimpan waiter_task = waiter->task, lalu memproses dengan urutan berikut
    1. Mengunci waiter_task->pi_lock
    2. Menghapus waiter dari antrean rtmutex
    3. Menetapkan waiter_task->pi_blocked_on = NULL
    4. Meneruskan waiter_task, bukan current, juga ke rt_mutex_adjust_prio_chain() berikutnya
  • Perbaikan terpisah yang dikirim peneliti sebelum v1 disusun agar pemanggil meneruskan task pemilik secara eksplisit
    • Pada jalur ketika dirinya sendiri diblokir, current diteruskan
    • Pada rollback proxy, task target proxy diteruskan
    • pi_blocked_on hanya dihapus ketika masih menunjuk ke waiter tersebut, dan dilindungi dengan pi_lock milik task

• RANDOMIZE_KSTACK_OFFSET

  • Eksploit bergantung pada overlap deterministik antara frame waiter yang telah dibebaskan dan frame user_auxv berikutnya
  • Jika RANDOMIZE_KSTACK_OFFSET diaktifkan, offset stack berubah sehingga tahap ini menjadi tebakan 5-bit dengan peluang sekitar 1/32
  • Pada dua target umum yang diajukan, pengaturan ini secara default nonaktif; pada target mitigasi pengaturan ini aktif, sehingga jalur eksploit tersebut tidak digunakan

• STATIC_USERMODE_HELPER

  • STATIC_USERMODE_HELPER memblokir jalur DirtyMode spesifik ini
  • Namun, metode yang sama dapat digeneralisasi ke pengaturan /proc/sys lain yang hak aksesnya dikendalikan oleh ctl_table::mode dan tabelnya berada pada data kernel yang dapat ditulisi dan dapat diprediksi

Jadwal pengungkapan

• 18 April 2026: Kerentanan dan draft patch disampaikan ke [e-mail]
• 20 April 2026: Kerentanan diperbaiki oleh patch lain
• 4 Mei 2026: Perbaikan v1 di-backport
• 30 Juni 2026: Google mengonfirmasi submission kernelCTF
• 7 Juli 2026: Analisis teknis dipublikasikan
• Kerentanan yang ditemukan VEGA menerapkan kebijakan pengungkapan standar 90+30 hari

[GN⁺]

Komentar Hacker News

• Diuji pada 3 perangkat yang menjalankan Android 9, 13, dan 16 serta berbagai versi Firefox di bawah 150; 2 perangkat masuk ke boot loop sehingga harus masuk mode pemulihan, sementara 1 perangkat lainnya mati. Demo mengubah wallpaper perangkat Pixel yang didukung, dan halaman uji dapat dilihat di IonStack.
  Saat membaca blog atau situs acak di perangkat pribadi, lebih aman memasang browser berbasis Chromium seperti Chromite secara terpisah dari browser utama, lalu mematikan JavaScript dan decoder video akselerasi hardware yang sering diserang lewat flags, dan memakai mode baca untuk situs yang rusak. Alternatifnya, bisa juga menyediakan tablet khusus.

  • Saat ini baru diuji pada Pixel 10, tetapi ada beberapa PR yang berupaya mendukung perangkat lain, dan bisa dilihat di https://github.com/NebuSec/CyberMeowfia
  • Saat mencoba mem-port exploit kernel ke perangkat lain, ternyata ia sangat sensitif terhadap cara compiler menata stack frame pada setiap build kernel. Setelah menemukan metode stamping dan offset yang cocok untuk build tertentu, exploit berjalan cukup stabil.
  • Saya mengambil risiko menjalankannya di Samsung S26 Ultra; setelah memasang adb dan memeriksanya, saya akan mengungkap hasil lengkapnya.
    Saat membuka halaman uji, output muncul di tab Firefox sehingga sepertinya kode proof-of-concept berjalan, tetapi setelah itu ponsel membeku dan menolak semua input. Hanya restart yang berfungsi; saya penasaran bagaimana perangkat masih bisa merespons event restart ketika kernelnya tampak macet. Layar tetap menyala sambil menampilkan sebagian hasil eksekusi, lalu screen saver aktif.
  • Akan luar biasa jika ini bisa dimanfaatkan untuk me-root perangkat Android yang belum bisa di-root, tetapi saya penasaran bagaimana caranya.
  • Kerentanan Firefox tampaknya adalah CVE-2026-10702, type confusion pada compiler JIT IonMonkey: https://www.sentinelone.com/vulnerability-database/cve-2026-10702/

• Pujian besar untuk para peneliti keamanan yang bukan hanya menemukan exploit ini, tetapi juga tidak merilis skrip zero-day local privilege escalation yang bisa langsung dipakai siapa pun, berbeda dengan copyfail.
  Saya mencoba local privilege escalation (LPE) selama beberapa jam di Rocky Linux 9, tetapi untungnya tidak berhasil. Kecuali punya banyak waktu luang atau kemampuan yang sangat tinggi, tampaknya sulit memanfaatkannya dalam serangan nyata pada distro enterprise.

• Saya penasaran apakah kerentanan ini memungkinkan membuka kunci bootloader bahkan pada ponsel yang biasanya bootloader-nya tidak bisa dibuka. Jika memungkinkan, ini bisa menjadi salah satu kejadian terbaik yang pernah terjadi di ekosistem Android.

• Sepertinya judulnya seharusnya mencantumkan LPE yang berarti local privilege escalation, agar kebanyakan orang bisa merasa tenang dan kembali menikmati akhir pekan.

  • Ini bukan sesuatu yang sepenuhnya menenangkan. Biasanya exploit privilege lokal berarti serangan yang naik dari hak pengguna biasa ke root, dan aplikasi dengan hak biasa pun sudah bisa menimbulkan kerusakan besar, sehingga orang umumnya tidak terlalu khawatir.
    Namun serangan kali ini bisa dipicu bahkan dari dalam proses yang sangat di-sandbox, seperti proses browser Firefox yang terisolasi. Penyerang hanya perlu merangkai serangan dua tahap: menjalankan kode lokal di sandbox terisolasi melalui kerentanan JavaScript, lalu naik sampai mode kernel dengan kerentanan ini. Jadi Firefox dan kernel Linux sama-sama harus diperbarui.
  • Serangan di komentar induk tampak seperti langsung mendapatkan hak root dari JavaScript, tetapi sebenarnya ia merangkai dua exploit berbeda.
  • Kalau container escape memungkinkan, bukankah ini masih bisa berdampak pada banyak orang?
  • Karena kerentanan type confusion Firefox/IonMonkey juga ditemukan bersamaan, perangkat bisa diambil alih dengan sangat cepat hanya dengan mengunjungi situs web sembarang.
  • Rasanya sekarang ada ratusan zero-day yang ditimbun untuk situasi seperti ini. Dari SSH sampai Node.js, masalah baru muncul setiap beberapa minggu; kecuali semua komunikasi ditempatkan di balik WireGuard, praktis semuanya harus diperlakukan seperti kerentanan jarak jauh.

• Bagian yang menyebut “Google membayar 92.337 dolar sebagai hadiah kernelCTF” langsung menarik perhatian.

  • Mengingat cakupan dampaknya, jumlah itu terasa kecil. Saya penasaran apakah perusahaan hanya membayar besar untuk exploit jarak jauh.

• Saya penasaran apakah ini berarti aplikasi Android bisa menjalankan kode native dengan NDK dan mendapatkan hak root, serta apakah SELinux membantu bertahan.

  • Ponsel non-flagship jarang menerima pembaruan, termasuk kernel, jadi kemungkinan besar hal itu benar-benar memungkinkan.
    Patch memang bisa di-backport ke kernel lama, tetapi changelog pembaruan smartphone jarang mencantumkan CVE, sehingga alat pemeriksa kerentanan praktis menjadi satu-satunya cara untuk memastikan. Jika aplikasi dari Play Store atau sumber luar sudah dikompromikan, ia bisa langsung mendapatkan hak root; jadi prinsip memeriksa kepercayaan dan audit saat memasang aplikasi tetap penting.
    Ke depan, pemeriksaan ini mungkin ditambahkan ke semua level Google Play Integrity sehingga beberapa aplikasi tidak bisa dipasang pada ponsel yang belum dipatch. Pada browser, yang sulit menghindari situs acak dan iklan, ini lebih serius karena sandbox escape juga melewati isolasi aplikasi, mirip dengan JailbreakMe di iOS.
  • Jika kernelnya sendiri dikompromikan, SELinux tidak bisa bertahan. Sandbox Android maupun teknologi container seperti Docker juga tidak bisa mencegah exploit ini; sarana isolasi yang realistis hanyalah virtualisasi penuh. Jika menggunakan KVM, perlu asumsi bahwa patch CVE-2026-53359 yang dipublikasikan minggu lalu sudah didistribusikan ke semua tempat.
    Aplikasi apa pun yang dapat menjalankan kode native di Linux keluaran 15 tahun terakhir dapat memperoleh hak root sampai pembaruan kernel tiba di perangkat.

• Mengejutkan bahwa GhostLock masuk ke Linux 2.6.39 dan baru diperbaiki di Linux 7.1.

• Rasanya saya sudah membaca komentar-komentar ini sehari sebelumnya, tetapi waktu penulisannya semua ditampilkan dalam 10 jam terakhir; saya penasaran apakah tampilan waktu HN salah.

  • Kemungkinan besar ini akibat sistem re-up HN. Ketika tulisan ini dinaikkan lagi, timestamp komentar lama dihitung ulang sebagai waktu relatif; informasi terkait bisa dilihat di https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20timestamps%20re-up&sort=byDate&type=comment.
    Tulisan ini berada di posisi teratas dalam daftar “underwater” yang saya cek setiap hari, yaitu daftar tulisan yang mendapat banyak upvote tetapi karena alasan tertentu tidak sampai ke halaman depan, sehingga saya menampilkannya ulang. Memang terlihat aneh, tetapi belum ada alternatif yang tidak terlalu membingungkan.
  • Kadang artikel-artikel serupa digabung menjadi satu, bahkan komentarnya ikut digabung.