From: Lukas Gerlach lukas.gerlach@cispa.de
[ Upstream commit 25fd7ee7bf58ac3ec7be3c9f82ceff153451946c ]
The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.
Signed-off-by: Lukas Gerlach lukas.gerlach@cispa.de Link: https://patch.msgid.link/20251218191332.35849-3-lukas.gerlach@cispa.de Signed-off-by: Paul Walmsley pjw@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## Commit Analysis: riscv: Sanitize syscall table indexing under speculation
### 1. COMMIT MESSAGE ANALYSIS
The commit message clearly describes a **security vulnerability fix**: - User-controlled syscall numbers are used to index into the syscall table - The fix prevents speculative out-of-bounds access - Addresses data leakage via cache side channels (Spectre v1-style attack)
Key indicators: "speculative out-of-bounds access", "data leakage", "cache side channels" - these are unmistakable security vulnerability descriptions.
### 2. CODE CHANGE ANALYSIS
The change is minimal and surgical:
```c - if (syscall >= 0 && syscall < NR_syscalls) + if (syscall >= 0 && syscall < NR_syscalls) { + syscall = array_index_nospec(syscall, NR_syscalls); syscall_handler(regs, syscall); + } ```
**Technical mechanism:** - The bounds check (`syscall >= 0 && syscall < NR_syscalls`) is performed at runtime - However, speculative execution can bypass this check - the CPU may speculatively execute `syscall_handler()` with an out-of-bounds index before the branch is resolved - This speculative access leaves traces in the cache that can be measured via timing attacks - `array_index_nospec()` creates a data dependency that architecturally clamps the index, preventing speculative OOB access
This is the standard Spectre v1 (bounds check bypass) mitigation pattern used extensively throughout the kernel since 2018.
### 3. CLASSIFICATION
**Type:** Security fix (speculative execution side-channel vulnerability)
This is NOT: - A new feature - A code cleanup - An optimization - A refactoring
This IS a security hardening fix addressing a well-known class of vulnerabilities.
### 4. SCOPE AND RISK ASSESSMENT
**Size:** 2 lines of actual code change **Files:** 1 file (arch/riscv/kernel/traps.c) **Complexity:** Extremely low - standard pattern
**Risk analysis:** - `array_index_nospec()` is a mature, battle-tested macro available since kernel 4.16+ - The logic flow is identical - only adds speculation barrier - No functional behavior change - Zero regression risk - this is purely defensive
### 5. USER IMPACT
**Affected users:** All RISC-V kernel users
**Severity:** High - this is a security vulnerability: - Allows potential kernel memory disclosure via timing side-channels - Spectre-class vulnerabilities have resulted in numerous CVEs - The syscall path is one of the most critical attack surfaces (user → kernel transition)
**Real-world impact:** While exploitation requires sophistication, Spectre attacks are well-documented and actively exploited. This vulnerability class affects every major cloud provider and is taken very seriously.
### 6. STABILITY INDICATORS
- Authored by researcher from CISPA (Helmholtz Center for Information Security) - Signed-off by Paul Walmsley (RISC-V maintainer) - Follows established kernel security patterns - Other architectures (x86, ARM64) already have equivalent protections
### 7. DEPENDENCY CHECK
**`array_index_nospec()`:** This macro has been in the kernel since early 2018 (v4.16) for Spectre mitigations. It will be present in all maintained stable trees.
**Code context:** The `do_trap_ecall_u()` function in `arch/riscv/kernel/traps.c` is a fundamental part of the RISC-V syscall handling and exists in all stable trees supporting RISC-V.
No other commits are required as dependencies.
### STABLE KERNEL RULES ASSESSMENT
| Criteria | Assessment | |----------|------------| | Obviously correct | ✅ Uses standard kernel pattern | | Fixes real bug | ✅ Security vulnerability | | Important issue | ✅ Information disclosure via side-channel | | Small and contained | ✅ 2 lines, 1 file | | No new features | ✅ Pure security hardening | | Can apply cleanly | ✅ Self-contained change |
### CONCLUSION
This is an exemplary stable backport candidate:
1. **Security fix** for a Spectre v1-class vulnerability in the RISC-V syscall path 2. **Minimal change** - 2 lines using well-established kernel security primitives 3. **Zero regression risk** - no functional change, only speculation barrier 4. **High value** - protects all RISC-V users from potential kernel memory disclosure 5. **Brings RISC-V in line** with other architectures that already have this protection
The fix is small, surgical, addresses a real security vulnerability, uses a mature mitigation pattern, and has essentially no risk of causing regressions. This meets all stable kernel criteria.
**YES**
arch/riscv/kernel/traps.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 80230de167def..47afea4ff1a8d 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -339,8 +339,10 @@ void do_trap_ecall_u(struct pt_regs *regs)
add_random_kstack_offset();
- if (syscall >= 0 && syscall < NR_syscalls) + if (syscall >= 0 && syscall < NR_syscalls) { + syscall = array_index_nospec(syscall, NR_syscalls); syscall_handler(regs, syscall); + }
/* * Ultimately, this value will get limited by KSTACK_OFFSET_MAX(),