Rust Borrow Checker Punya Lubang Soundness 11 Tahun, Ini Detail Issue 164250

Rust menutup satu lubang soundness di borrow checker yang sudah terbuka lebih dari 11 tahun. Issue rust-lang/rust nomor 164250, dibuka 13 Oktober 2026 oleh pengguna jsnell, melaporkan bahwa syarat lifetime sebuah struct bisa dilewati lewat covariant field assignment, dan tim compiler menandainya P-high dengan label I-unsound. Akar masalahnya ada di issue 25860 yang dibuka aturon pada 28 Mei 2015, sehingga usia lubang ini genap 11 tahun sebelum akhirnya ramai dibahas publik.

TL;DR

• Issue rust-lang/rust 164250 (13 Oktober 2026) melaporkan syarat lifetime sebuah struct bisa dilewati lewat covariant field assignment ditambah implementasi Drop kustom.
• Akar masalahnya issue 25860, dibuka 28 Mei 2015: kombinasi variance dan implied bounds pada nested reference.
• Labelnya P-high, I-unsound, A-variance, A-borrow-checker, dan A-destructors, dan statusnya masih open sampai sekarang.
• Tim Types Rust menyebut lubang ini belum pernah terdeteksi di alam liar selama 11 tahun, jadi risiko untuk kode aplikasi biasa kecil.
• Penambalan menyeluruh menunggu next-generation trait solver dan region constraint rework, bukan sekadar tambalan cepat.

Apa sebenarnya yang bocor di borrow checker Rust?

Yang bocor adalah jaminan lifetime, bukan memori secara langsung. Rust memakai variance dan implied bounds untuk menyimpulkan hubungan umur antar referensi, dan pada kombinasi tertentu keduanya membuat compiler menerima kode yang seharusnya ditolak.

Variance adalah aturan kapan sebuah tipe boleh dianggap subtipe dari tipe lain. Referensi bersifat covariant terhadap lifetime, artinya referensi yang hidup lebih lama bisa dipakai di tempat yang menuntut umur lebih pendek. Masalahnya, saat sifat covariant itu bertemu assignment ke field struct dan implementasi Drop buatan sendiri, compiler bisa menyimpulkan batas umur yang lebih longgar daripada yang benar-benar berlaku. Contoh paling ringkas yang dilaporkan adalah fungsi yang mengembalikan referensi dengan lifetime statis padahal argumennya berumur pendek, lewat perantara function pointer.

static UNIT: &'static &'static () = &&();

fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

Pada kasus itu, parameter yang dibuang dengan underscore membuat relasi antar lifetime tidak lagi diikat dengan benar. Kode yang lolos pemeriksaan borrow checker seharusnya tidak boleh mengembalikan referensi berumur statis dari data berumur pendek, karena pemanggil bisa memakai referensi itu setelah sumbernya sudah dihapus.

Kabar baiknya, tim compiler sudah pernah menambal satu varian lubang ini di issue 129021 untuk function pointer non-higher-ranked. Yang tersisa adalah bentuk yang belum tertutup, dan itulah yang membuat issue 164250 tetap dibuka dengan label I-unsound.

Kenapa lubang 11 tahun ini baru ramai sekarang?

Karena laporan barunya menyertakan contoh yang jauh lebih sederhana daripada contoh tahun 2015. Issue 25860 asli ditulis dengan contoh yang bergantung pada function pointer dan nested reference yang cukup rumit, sehingga mudah dianggap kasus tepi yang jarang ditemui. Laporan 164250 memangkasnya jadi beberapa baris yang bisa dibaca sekali duduk, dan begitu contohnya ringkas, diskusi di kalangan developer langsung meledak.

Ada faktor kedua: issue 106431 yang dibuka Manishearth pada 4 Januari 2023 sudah menandai bahwa well-formedness referensi memperlakukan lifetime contravariant sama seperti covariant. Saat itu temuan tersebut sempat memicu bug soundness nyata di crate Yoke milik proyek ICU4X. Artinya jejak masalah ini sudah pernah menyentuh kode orang lain, meski akhirnya bisa dihindari lewat perbaikan di sisi crate.

Jadi yang baru bukan lubangnya, melainkan bukti bahwa lubang itu bisa ditulis dalam bentuk yang jauh lebih pendek. Itu mengubah penilaian risiko: dari kasus tepi yang teoritis menjadi sesuatu yang mungkin ditemukan orang lain dengan cepat.

Apa dampaknya buat kode Rust yang sudah jalan di produksi?

Untuk mayoritas aplikasi, dampaknya kecil. Tim Types Rust menegaskan bahwa bug ini berlabel P-high, bukan P-critical, justru karena usianya 11 tahun: lubang yang tidak ditemukan selama lebih dari satu dekade tidak mungkin terlalu mudah kena secara tidak sengaja. Mereka juga menilai kecil kemungkinan lubang ini sudah pernah menyebabkan memory unsafety tanpa sengaja di kode orang.

Yang lebih perlu diwaspadai adalah kode yang memakai unsafe, generic lifetime yang rumit, atau tipe self-referential seperti yang lazim di crate parsing dan zero-copy. Di area itu, asumsi bahwa compiler sudah membuktikan keamanan lifetime perlu ditinjau ulang sampai perbaikan resmi mendarat.

Issue	Dibuka	Inti masalah	Status
25860	28 Mei 2015	Implied bounds pada nested reference plus variance	Open
106431	4 Januari 2023	Lifetime contravariant diperlakukan sama seperti covariant	Open
164250	13 Oktober 2026	Lifetime requirement struct dilewati lewat covariant field assignment	Open, P-high

Bagaimana cara mengecek kode sendiri terhadap lubang ini?

Mulai dari tiga hal yang paling sering jadi pemicu: blok unsafe, tipe self-referential, dan generic yang memakai for dengan bound lifetime eksplisit. Tiga pola itu yang paling mungkin menyembunyikan asumsi lifetime yang salah, dan ketiganya bisa dicari dengan alat yang sudah tersedia tanpa menunggu perbaikan compiler.

Langkah praktisnya cukup sederhana. Pertama, kumpulkan setiap blok unsafe di kodebase dan tulis ulang alasan kenapa blok itu aman. Kalau alasannya berbunyi karena compiler menerimanya, itu bukan alasan yang sah untuk unsafe. Kedua, cari tipe yang menyimpan referensi ke data miliknya sendiri, karena tipe seperti itu bergantung penuh pada batas lifetime yang ketat. Ketiga, jalankan Miri pada unit test untuk menangkap pelanggaran aturan aliasing dan lifetime yang lolos dari borrow checker biasa.

Kalau kamu memakai crate yang menawarkan abstraksi zero-copy, baca juga issue tracker crate tersebut. Bug soundness sering dilaporkan lebih dulu di level crate sebelum masuk ke compiler, seperti yang terjadi pada Yoke di proyek ICU4X ketika issue 106431 memunculkan efek nyatanya.

Mengapa variance dan Drop bisa bertabrakan?

Karena Drop memberi struct kesempatan menjalankan kode saat nilainya dihancurkan, dan compiler harus membuktikan bahwa data yang diakses di dalam Drop masih hidup. Mekanisme ini disebut drop check. Ketika field struct bersifat covariant terhadap lifetime, compiler mengizinkan substitusi umur yang lebih pendek, tetapi analisis drop check bisa memakai batas umur yang berbeda dan lebih longgar, sehingga celah muncul di antara keduanya.

Yang membuat celah ini licin adalah sifatnya yang kumulatif. Masing-masing bagian, variance, implied bounds, dan drop check, dirancang dengan asumsi yang masuk akal saat ditulis. Baru ketika ketiganya bertemu dalam satu kasus, muncul kombinasi yang tidak pernah diperhitungkan. Itulah kenapa memperbaikinya butuh rework pada cara compiler mewakili batas region, bukan sekadar menambah satu pengecekan di akhir.

Untuk pengembang aplikasi, pelajaran praktisnya: jangan menulis implementasi Drop pada struct yang punya field generic lifetime rumit kecuali benar-benar perlu. Semakin sederhana interaksi antara lifetime dan destructor, semakin kecil permukaan yang bisa bocor.

Apa reaksi komunitas dan tim Rust?

Reaksinya cepat dan sebagian besar bernada tenang. Tim compiler langsung menambahkan catatan konteks di issue, menjelaskan bahwa mereka menangani semua unsoundness type system sebagai prioritas serius lewat Project Zero, dan bahwa label P-high dipilih justru karena usia bug, bukan karena tingkat bahayanya. Penjelasan itu cukup meneduhkan karena menunjukkan tim sudah lama menyadari masalahnya.

Di sisi komunitas, perdebatan bergeser ke pertanyaan yang lebih menarik: bagaimana sebuah lubang bisa bertahan 11 tahun tanpa terdeteksi. Jawabannya ada pada bentuk contohnya. Selama bertahun-tahun lubang ini hanya bisa ditulis dengan konstruksi rumit, sehingga tidak muncul di kode orang. Begitu ada yang menemukan bentuk ringkasnya, jumlah orang yang bisa memverifikasi temuan itu melonjak dalam hitungan jam, dan di situlah nilai sebenarnya dari laporan baru ini.

Apakah lubang ini bisa dieksploitasi jadi serangan nyata?

Secara teori bisa, tetapi praktiknya sulit. Untuk berubah menjadi memory unsafety, penyerang harus lebih dulu menanam kode Rust dengan pola lifetime tertentu di dalam program korban, dan itu berarti ia sudah punya kemampuan menulis kode di proyek tersebut. Lubang seperti ini lebih berbahaya sebagai bug kestabilan pada kode yang salah tulis daripada sebagai jalur serangan jarak jauh.

Yang membuatnya tetap penting adalah efek berantainya. Satu crate yang salah memakai pola ini bisa membuat seluruh aplikasi yang bergantung padanya rentan, dan dalam ekosistem Rust yang saling bergantung lewat Cargo, satu kesalahan kecil bisa menjalar jauh. Karena itu tim Rust memperlakukan setiap laporan I-unsound sebagai prioritas, meski peluang eksploitasinya kecil.

Untuk kamu yang menulis library, ini alasan tambahan untuk menguji kode dengan Miri dan menyertakan contoh pemakaian yang benar. Semakin jelas batas lifetime yang kamu janjikan di dokumentasi, semakin kecil kemungkinan pengguna crate memakai API-mu dengan cara yang membuka celah ini tanpa sadar.

Kapan perbaikannya datang?

Belum ada tanggal rilis pasti, tetapi arah perbaikannya sudah terlihat. Tim Types Rust menargetkan penambalan lewat tiga pekerjaan besar: next-generation trait solver, region constraint rework, dan inisiatif yang mereka sebut Project Zero untuk memburu seluruh lubang type system.

Perbaikan seperti ini tidak bisa dijadikan patch cepat, karena mengubah cara compiler menyimpulkan batas lifetime berisiko menolak kode valid yang sudah beredar luas. Itulah alasan lubang bertahan 11 tahun: memperbaikinya dengan benar lebih berisiko daripada membiarkannya, selama belum ada bukti eksploitasi nyata. Sampai rilis resmi keluar, cara paling aman adalah memantau issue 164250 dan menghindari pola generic lifetime yang tidak perlu di kode baru.

FAQ

Apakah ini artinya Rust tidak aman dipakai?

Bukan. Lubang ini hanya bisa memicu memory unsafety kalau ditulis dengan sengaja dalam bentuk tertentu, dan selama 11 tahun belum ada laporan kode produksi yang terkena tanpa sengaja. Rust tetap jauh lebih aman daripada bahasa tanpa pemeriksaan lifetime sama sekali.

Apakah kode Rust saya ikut kena?

Kemungkinan besar tidak. Kode aplikasi yang tidak memakai unsafe dan tidak menulis generic lifetime rumit aman. Yang perlu waspada adalah crate low-level seperti parser, zero-copy buffer, dan tipe self-referential yang bergantung pada batas lifetime ketat.

Kapan Rust akan menambal lubang ini?

Belum ada jadwal resmi. Penambalannya bergantung pada next-generation trait solver dan region constraint rework yang masih dalam pengerjaan. Pantau issue 164250 dan catatan roadmap Types Team untuk tanggalnya.

Apa yang harus saya lakukan sekarang?

Tidak ada tindakan darurat. Perbarui toolchain seperti biasa, hindari menambah pola lifetime eksotis di kode baru, dan kalau kamu menulis unsafe, pastikan asumsi lifetime-nya diuji dengan benar alih-alih hanya mengandalkan penerimaan compiler.

Kasus ini pengingat bahwa jaminan compiler itu hasil bukti matematis, dan bukti bisa punya celah yang belum ditemukan. Dokumentasi resmi soal variance ada di Rustonomicon, sementara rencana perbaikan tipe system dirinci di halaman Project Goals Rust. Sampai keduanya selesai, anggap lubang ini sebagai utang teknis yang diketahui, bukan alasan panik.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.