- Son 7 gün
CVE-2026-99016
Linux çekirdeğinde RISC-V futex işleminde etiketli kullanıcı işaretçisinin atomik erişimden önce temizlenmemesi sorunu
- Yayımlandı
- Güncellendi
- 24 Eki 2026
- Açık yaşı
- 5 gün
- Kaydı açan
- Linux
ÖzetTürkçe
Linux çekirdeğinde, access_ok denetimi untagged_addr(uaddr) üzerinden yapılırken arch_futex_atomic_op_inuser ve futex_atomic_cmpxchg_inatomic fonksiyonları ham uaddr değerini satır içi assembly (amoswap/amoadd/.../lr.w+sc.w) işlemlerine iletmektedir. Etiketli adres ABI'si etkinleştirildiğinde (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL ile PMLEN != 0) bu iki adres farklı olabilmektedir; en üst PMLEN bitinde etiket bulunduran bir kullanıcı işaretçisi, temizlendikten sonra access_ok denetimini geçer, ancak atomik işlem hâlâ etiketli ham adres üzerinde gerçekleştirilir. Denetim modundaki veri erişimleri U-mod işaretçi maskelemesine tabi değildir (bu, çekirdeğin ayarlamadığı menvcfg.PMM ile yönetilir), dolayısıyla donanım çekirdeğin kendi erişiminden etiketi ayıklamaz. Sv57 ve PMLEN=16 durumunda etiket bitleri kanonik adres bitleriyle çakışır; bu nedenle etiketli bir işaretçi, temizlenmiş hâlde geçerli bir kullanıcı adresi olan kanonik bir çekirdek sanal adresine (örneğin doğrusal eşlemede) işaret edebilir. Ayrıcalıksız bir süreç bu yolla FUTEX_WAKE_OP ile keyfi bir çekirdek adresinde atomik okuma-değiştirme-yazma işlemi gerçekleştirebilir ve eşleşen FUTEX_OP_CMP_* sonucu okuma oracle'ı olarak kullanılabilir. get_user, put_user ve raw_copy_{to,from}_user fonksiyonları access_ok denetiminden sonra işaretçiyi zaten temizlemektedir; düzeltme, futex yardımcı fonksiyonlarında da aynısını yaparak atomik işlemin doğrulanan adres üzerinde çalışmasını sağlamaktadır.
Kaynaktaki açıklama (İngilizce)
In the Linux kernel, the following vulnerability has been resolved:
riscv: futex: untag the user pointer before the atomic access
access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser()
and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm
amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the
tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl
PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a
user pointer whose top PMLEN bits hold a tag passes access_ok() after
untagging, but the atomic is then performed on the still-tagged raw
address.
Supervisor-mode data accesses are not subject to the U-mode pointer
masking (that is governed by menvcfg.PMM, which the kernel does not set),
so hardware does not strip the tag for the kernel's own access. With
Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a
tagged pointer can name a canonical kernel virtual address (e.g. in the
linear map) whose untagged form is a valid user address. An unprivileged
process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on
an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result
serving as a read oracle.
get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer
after the access_ok() check; do the same in the futex helpers so the
atomic operates on the address that was actually validated.
Bu açığın açıklamasını Türkçeye çevirdik. Adım adım çözüm önerilerini kritik ve yeni açıklar için hazırlıyoruz; düzeltilmiş sürüm aşağıdaki tabloda, ayrıntılar üreticinin duyurusunda.
Etkilenen sürümler1 yazılım
| Yazılım | Etkilenen | Düzeltildiği sürüm |
|---|---|---|
| Linux | 6.13 | – |
| < 6.13 Etkilenmiyor | – | |
| ≥ 6.18.57 Etkilenmiyor | – | |
| ≥ 7.2.11 Etkilenmiyor | – |
Kaynaklar5 kaynak
Kayıt geçmişi
- Yayımlandı
İlgili açıklar
Türkçe metin, resmi kayıtlardaki bilgilerle yapay zekâ yardımıyla yazıldı ve yayından önce otomatik kontrollerden geçti. Bir değişikliği uygulamadan önce üreticinin duyurusuna mutlaka bakın.