CVE-2024-35873

What it actually does

The flaw incorrectly marks the live vector state as dirty during rt_sigreturn() after discarding it on syscall entry, causing the subsequent vectorized user_from_copy() restore (when CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD triggers) to overwrite the vstate with the discarded dirty state and corrupt vector registers, vl, vtype, and vstart.

Why it matters to the business

RISC-V workloads that use vector extensions and handle signals experience unexpected process crashes, leading to service disruption and potential data loss on unpatched kernels; the issue is widespread in the Linux ecosystem given the number of downstream dependents.

How an attack unfolds

An attacker triggers signals against a target process that is actively using vector instructions; on return from the signal handler the rt_sigreturn path discards live state, restores vstate without registers, then restores registers via the vectorized copy routine that saves the dirty state back into vstate, leaving the process with corrupted vector context that crashes on resume.

How to fix it

Upgrade the Linux kernel to version 6.8.5 or later, or apply commit 5b16d904e910183181b9d90efa957c787a8ac91b; rebuild and reboot affected systems; for systems where immediate upgrade is not possible, set CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD to a value that disables vectorized copy or disable vector extensions if feasible.

How to confirm the fix worked

Confirm the running kernel reports version 6.8.5 or newer; inspect /proc/config.gz or kernel build logs for the applied commit hash; run regression tests that exercise vector code paths with signal delivery on RISC-V hardware with vlen > 128 bits.

Typical attack path

1. Identify or create a RISC-V process executing vector code with vlen > 128 bits
2. Deliver a signal to the process
3. Process enters signal handler and later returns via rt_sigreturn syscall
4. Live vector state is discarded and marked dirty
5. vstate is restored from sigcontext except registers
6. Vector registers are restored via vectorized user_from_copy, corrupting vstate
7. Process resumes with invalid vector context and crashes

How to detect it

Search kernel and application logs for unexpected segmentation faults or illegal instruction traps immediately following signal returns on RISC-V systems; correlate with processes that have used vector instructions (check /proc/<pid>/status for vector context); review audit logs for rt_sigreturn syscalls preceding crashes.

What your security team should do

• Prioritize patching all RISC-V systems to 6.8.5 or the backported commit within the next maintenance window
• Add kernel version checks to vulnerability scanning and asset inventory
• Monitor RISC-V application crash rates and signal-related vector faults
• Test vector workloads with signals in staging before production rollout of the fix