https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 24 Oct 2026 20:09:34 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99018 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp</p> <p>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:</p> <p>beq \prev, tp, _skip_scs scs_load_current _skip_scs:</p> <p>tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (&amp;current) 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 &#34;sd ra, -8(gp)&#34; / &#34;ld ra, -8(gp)&#34; 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.</p> <p>Decide &#34;came from userspace&#34; 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 a…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp</p> <p>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:</p> <p>beq \prev, tp, _skip_scs scs_load_current _skip_scs:</p> <p>tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (&amp;current) 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 &#34;sd ra, -8(gp)&#34; / &#34;ld ra, -8(gp)&#34; 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.</p> <p>Decide &#34;came from userspace&#34; 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 a…</p> https://db.gcve.eu/vuln/fkie_cve-2026-99018 https://db.gcve.eu/vuln/ghsa-7x79-hrpm-vw9w <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp</p> <p>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:</p> <p>beq \prev, tp, _skip_scs scs_load_current _skip_scs:</p> <p>tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (&amp;current) 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 &#34;sd ra, -8(gp)&#34; / &#34;ld ra, -8(gp)&#34; 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.</p> <p>Decide &#34;came from userspace&#34; 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 a…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp</p> <p>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:</p> <p>beq \prev, tp, _skip_scs scs_load_current _skip_scs:</p> <p>tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (&amp;current) 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 &#34;sd ra, -8(gp)&#34; / &#34;ld ra, -8(gp)&#34; 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.</p> <p>Decide &#34;came from userspace&#34; 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 a…</p> https://db.gcve.eu/vuln/ghsa-7x79-hrpm-vw9w