A SpacemiT K3 developer reports that the Linux-6.18 signal-handling path trusts user-controlled vstate.vlenb without validation when CONFIG_SPACEMIT_HMP=y, pointing to a specific line in arch/riscv/kernel/signal.c.
K3 Linux Signal Handling Bug: Untrusted vstate.vlenb in CONFIG_SPACEMIT_HMP=y
A fresh bug report on the SpacemiT community forum highlights a trust-boundary issue in the SpacemiT Linux-6.18 kernel when the heterogeneous multi-processing option
CONFIG_SPACEMIT_HMP=y is enabled. The reporter, gorv256, notes that
current->thread.vstate.vlenb is treated as trusted kernel data in the signal restore path, even though its value originates from userspace and must be validated before use.
Where the Bug Lives
The referenced location is
arch/riscv/kernel/signal.c in the SpacemiT Linux-6.18 tree:
https://github.com/spacemit-com/linux-6.18/blob/k3-br-v1.0.y/arch/riscv/kernel/signal.c#L148
In the RISC-V signal frame design, the vector state saved to (and restored from) the signal context includes vlenb, the VLEN/8 byte value that describes the width of the vector registers. Because userspace can craft or modify a sigcontext, vlenb cannot be assumed to match the hardware capability or the kernel's own vector-state bookkeeping. Using it without range checks can lead to inconsistent vector register state, potential information leaks between processes, or a path to a kernel crash during signal return.
Why CONFIG_SPACEMIT_HMP=y Matters
CONFIG_SPACEMIT_HMP enables SpacemiT's heterogeneous multi-processing support on the K3 SoC. The K3 pairs eight
X100 application cores (RVA23, RVV with VLEN=256) with eight
A100 AI cores (VLEN=1024) for a combined 60 TOPS of AI compute. HMP is what lets the scheduler move work between the two core types, but it also means the kernel must handle vector contexts that may differ in width across the cluster boundary.
When a task migrates from an X100 core to an A100 core (or back), the vector save/restore path is exercised. If the signal-return code trusts a userspace-supplied vlenb, the kernel may allocate or copy the wrong amount of vector register data exactly when the heterogeneous transition happens. That makes this bug more than a static validation issue: it intersects with live task migration.
What a Proper Fix Looks Like
The standard kernel hardening pattern for this class of problem is:
- Reject any sigcontext vlenb that does not equal the kernel's known hardware vlenb for the current vector configuration.
- Treat a mismatch as a malformed signal frame and terminate the offending process with SIGSEGV, rather than trying to adapt.
- Audit the surrounding vector-state restore code for any other userspace-derived lengths or offsets that bypass validation.
A minimal patch would add a check such as:
if (vlenb != riscv_v_vlenb)
return -EINVAL;
before the vector register copy, where riscv_v_vlenb is the kernel-authoritative value established at boot. The exact symbol names will vary with the Spacemit tree, but the principle is the same:
never let userspace tell the kernel how large a kernel buffer is.
Practical Impact for K3 Users
- Normal applications that do not manipulate sigaltstack frames or hand-craft signal contexts are unlikely to trigger this directly.
- Programs that use custom signal handlers, JIT runtimes, language runtimes with segmented stacks, or any binary that restores vector state from a saved frame should be watched after the kernel is patched.
- Developers building container or sandbox workloads on K3 should treat this as a security-relevant fix and plan to update once SpacemiT releases a patched kernel.
Related K3 Platform Notes
The SpacemiT K3 is a serious piece of silicon: eight X100 cores at 2.4 GHz, eight A100 AI cores, 130K DMIPS, and enough on-chip NPU throughput to run a 30B-parameter LLM locally. It is also
RVA23-compliant and
Jetson-pin-compatible, which makes it a drop-in candidate for existing edge-AI carrier boards. Bugs like this one are normal early-life issues for a new SoC; what matters is how quickly they are isolated and fixed. The fact that the reporter provided a direct GitHub line reference makes this an easy issue for SpacemiT engineers to triage.
Source
Source:
Bug with CONFIG_SPACEMIT_HMP=y in SpacemiT Linux-6.18 by gorv256 on the SpacemiT community forum.
Compiled by Open RISC-V AI Assistant
For product inquiries, contact contact@open-riscv.com or visit /forum/inquiry