CVE-2026-99018
Beschrijving NL
In de Linux-kernel is de volgende kwetsbaarheid verholpen:
riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp
Onder CONFIG_SHADOW_CALL_STACK herlaadt handle_exception() de kernel.
Een schaduw-call stack pointer (gp) wordt alleen weergegeven wanneer de trap afkomstig is uit de gebruikersruimte. Het maakte die beslissing met scs_load_current_if_task_changed, die
vergelijkt de valtijd tp (teruglezen van sscratch naar s5) met de
huidige tp:
beq prev, tp, _skip_scs
scs_load_current
_skip_scs:
tp is een door de gebruiker te schrijven register. Een gebruikerstaak die tp instelt op de
lineair-map adres van zijn eigen task_struct (¤t) vóór trapping
zorgt ervoor dat de vergelijking slaagt (kan met brute force bereikt worden met KASLR)
(ingeschakeld tijdens onze test), waardoor de kernel scs_load_current overslaat en
blijft draaien met de groepsbeleidsregels die de gebruikersruimte heeft achtergelaten. Onder
CONFIG_SHADOW_CALL_STACK gp is de pointer naar de schaduwoproepstack en
load_global_pointer is een no-op, dus de compiler-gegenereerde
"sd ra, -8(gp)" / "ld ra, -8(gp)" in elke niet-bladfunctie en schrijf dan
naar, en terug via, een door de aanvaller beheerd adres -- een
Een primitief voor willekeurige schrijfbewerkingen en controle-flow-kaping van de kernel zonder privileges. De vergiftigde gp wordt bij terugkeer opgeslagen in task_struct.scs_sp, zodat de herlaadactie mislukt.
wordt ook bij elke volgende invoer overgeslagen. Bepaal of de informatie afkomstig is uit de gebruikersruimte op basis van de hardware sstatus.SPP-bit (dit is al het geval).
in s1 op dit punt) in plaats van vanuit tp, waarmee de controle wordt weerspiegeld die
ret_from_exception gebruikt al een paar instructies later. SPP is
Geschreven door hardware bij het betreden van de trap en kan niet worden vervalst vanuit de U-modus. Het legitieme gedrag blijft ongewijzigd: gebruikersinvoer (SPP=0) herlaadt de taak.
Shadow call stack, nested kernel entries (SPP=1) skip it.
Origineel (Engels) tonen
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.