- Son 7 gün
CVE-2026-99018
Linux çekirdeğinde RISC-V gölge çağrı yığınının yeniden yüklenmesi, tp yerine sstatus.SPP ile denetlenmeli: ayrıcalık yükseltme riski
- Yayımlandı
- Güncellendi
- 24 Eki 2026
- Açık yaşı
- 5 gün
- Kaydı açan
- Linux
ÖzetTürkçe
Linux çekirdeğinin RISC-V mimarisindeki kesme/istisna giriş kodunda (riscv: entry), CONFIG_SHADOW_CALL_STACK etkinken gölge çağrı yığını işaretçisinin (gp) yeniden yüklenmesi yanlış bir koşula dayanıyor. handle_exception işlevi, tuzağın kullanıcı alanından gelip gelmediğini belirlerken trap anındaki tp değerini mevcut tp ile karşılaştırıyor. tp kullanıcı tarafından yazılabilen bir yazmaç olduğundan, kullanıcı görevi tp değerini kendi task_struct yapısının doğrusal eşleme adresine (¤t) ayarlayarak bu karşılaştırmayı başarıyla geçebilir; KASLR etkinken bu değer kaba kuvvetle de elde edilebilir. Bu durumda çekirdek scs_load_current işlemini atlar ve kullanıcının bıraktığı gp ile çalışmaya devam eder. Gölge yığın modunda gp bir gölge yığın işaretçisi olduğundan, derleyicinin ürettiği "sd ra, -8(gp)" ve "ld ra, -8(gp)" komutları saldırgan denetimindeki bir adrese yazar ve bu adresten döner; bu da yetkisiz bir çekirdek rastgele yazma ve kontrol akışı ele geçirme olanağı sağlar. Zehirlenmiş gp değeri task_struct.scs_sp alanına kaydedildiğinden, sonraki tüm girişlerde yeniden yükleme atlanmaya devam eder. Düzeltmede, kullanıcı alanından gelinip gelinmediği tp yerine donanım tarafından tuzak girişinde yazılan sstatus.SPP biti (s1 yazmacında) ile belirlenir; bu, ret_from_exception içinde birkaç komut sonra zaten kullanılan denetimle aynıdır. SPP biti U modundan sahte olarak değiştirilemez. Meşru davranış değişmez: kullanıcı girişleri (SPP=0) görevin gölge çağrı yığınını yeniden yükler, iç içe çekirdek girişleri (SPP=1) bunu atlar. Etkilenen sürüm aralığı: 6.7 sürümü; 6.12.113, 6.18.57 ve 7.2.11 ile sonrasındaki sürümler etkilenmez. CVSS 3.1 puanı 7.8 (YÜKSEK), vektör: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
Kaynaktaki açıklama (İngilizce)
In the Linux kernel, the following vulnerability has been resolved:
riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp
Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel
shadow call stack pointer (gp) only when the trap came from userspace.
It made that decision with scs_load_current_if_task_changed, which
compares the trap-time tp (read back from sscratch into s5) against the
current tp:
beq \prev, tp, _skip_scs
scs_load_current
_skip_scs:
tp is a user-writable register. A user task that sets tp to the
linear-map address of its own task_struct (¤t) before trapping
makes the comparison succeed (can achieve by brute force with KASLR
enable under our test), so the kernel skips scs_load_current and
keeps running with the gp that userspace left in place. Under
CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and
load_global_pointer is a no-op, so the compiler-emitted
"sd ra, -8(gp)" / "ld ra, -8(gp)" in every non-leaf function then write
to, and return through, an attacker-controlled address -- an
unprivileged kernel arbitrary-write and control-flow-hijack primitive.
The poisoned gp is saved to task_struct.scs_sp on return, so the reload
is skipped on every subsequent entry as well.
Decide "came from userspace" from the hardware sstatus.SPP bit (already
in s1 at this point) instead of from tp, mirroring the check that
ret_from_exception already uses a few instructions later. SPP is
written by hardware on trap entry and cannot be forged from U-mode.
Legitimate behaviour is unchanged: user entries (SPP=0) reload the task
shadow call stack, nested kernel entries (SPP=1) skip it.
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.7 | – |
| < 6.7 Etkilenmiyor | – | |
| ≥ 6.12.113 Etkilenmiyor | – | |
| ≥ 6.18.57 Etkilenmiyor | – | |
| ≥ 7.2.11 Etkilenmiyor | – |
Kaynaklar6 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.