[PATCH AUTOSEL 6.18-6.12] riscv: Sanitize syscall table indexing under speculation

[Sasha Levin]

From: Lukas Gerlach <lukas.gerlach at 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 at cispa.de>
Link: https://patch.msgid.link/20251218191332.35849-3-lukas.gerlach@cispa.de
Signed-off-by: Paul Walmsley <pjw at kernel.org>
Signed-off-by: Sasha Levin <sashal at 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(),
-- 
2.51.0