Definition

An architectural CPU vulnerability is a security-relevant architectural bug: a mismatch between a CPU's specification and its implementation. The RISCVuzz paper contrasts these bugs with transient-execution attacks such as Meltdown and Spectre, which exploit optimizations such as out-of-order and speculative execution but still follow the architectural specification, leaking data only through microarchitectural traces. Architectural bugs, by contrast, can produce direct, reliable exploitation primitives with severe security impact.

Security relevance

Architectural CPU vulnerabilities are especially critical when they can be triggered from unprivileged user space. RISCVuzz argues that restricting testing to user space acts as an automated filter for security-critical bugs: denial-of-service behavior reachable only from machine or supervisor mode has limited impact in typical threat models, while bugs triggerable by unprivileged applications pose a significant threat. User-space testing can also run in sandboxed environments such as Docker containers or Android apps, broadening the realistic attack surface.

Potential impacts demonstrated in the evidence include:

• Denial of service, including CPU-halting instruction sequences reachable from unprivileged applications and even from inside Docker containers.
• Arbitrary memory read/write, demonstrated by the GhostWrite attack on the T-Head XuanTie C910, where unprivileged users could read and write arbitrary memory including machine-mode code and MMIO-mapped devices, fully breaking confidentiality and integrity.
• Privilege escalation, demonstrated by GhostWrite-based attacks that inject and execute code in supervisor- and machine-mode contexts, escalating to root and machine-mode privileges.
• Cryptographic fault attack, where GhostWrite was used to mount an effective fault attack that fully recovered a 2048-bit RSA key within 30 minutes by inducing faulty behavior in cryptographic operations.
• Cloud exploitation, confirmed by reproducing the GhostWrite vulnerability on Scaleway's TH1520 bare-metal cloud instances from unprivileged users.
• Silent data corruption, such as observed behavior where an operation wrote -1 instead of 0.

Examples

The Pentium F00F Bug is cited as an architectural-bug example: it allowed unprivileged users to lock systems via an invalid instruction. RISCVuzz also reports architectural bugs in RISC-V CPUs and emulators, including undocumented instructions, address-handling bugs, decoder bugs, ISA incompatibilities, fault-reporting issues, and QEMU segmentation faults. Specific findings reported by RISCVuzz include:

• GhostWrite (T-Head XuanTie C910): A bug in the vector extension (v0.7.1) where illegally-encoded vector-store instructions produce no exception on the C910 despite causing a segmentation fault on the C906, enabling unprivileged arbitrary physical-memory read/write.
• C906 CPU-halting instructions: Halt the CPU when triggered from unprivileged applications and from inside Docker containers; the responsible vendor extension cannot be disabled, leaving no mitigation.
• C908 CPU-halting instructions: Illegally encoded vector instructions close to but outside the vector extension that halt the C908 from unprivileged execution.
• Half-precision floating-point bugs: The C906 and C910 execute fsqrt.h and fmv.x.h even when the rs2 field is set to 0, contrary to the ISA specification.
• fcsr register bug: The C906 and C910 do not ignore writes to bits 8–10 of the fcsr register as the specification requires.
• Vector extension subset differences: The C910 and C908 each support a different subset of vector instructions, with some doing nothing, others producing unexpected results, and some not implemented at all.
• QEMU crashes: Cache-block management instructions such as cbo.inval crash QEMU 9.0.0 and 8.2.2 with a segmentation fault; truncating vector conversion instructions such as vfncvt.rtz.x.f.w crash QEMU 7.2.0 due to an assertion failure.
• Fault-reporting inconsistencies: SiFive CPUs tend to raise bus faults while T-Head CPUs raise segmentation faults; the C910 rounds reported fault addresses up to the next multiple of 16 when the address modulo 16 is greater than 8; the C908 raises segmentation faults for valid non-aligned addresses where a bus error is correct.

Relationship to transient-execution vulnerabilities

Transient-execution vulnerabilities such as Meltdown and Spectre exploit microarchitectural behavior caused by CPU optimizations like speculative and out-of-order execution. The evidence describes them as limited to read primitives because they follow the architectural specification and leak information only through microarchitectural traces. Architectural CPU vulnerabilities differ because they are implementation/specification mismatches and can therefore produce direct architectural effects including writes, code execution, and CPU halt.

Discovery approaches

Fuzzing is a common technique for finding unexpected hardware or software behavior. Differential fuzzing compares multiple implementations of the same specification and flags behavioral divergences as potential bugs without requiring a golden model. RISCVuzz applies this idea to closed-source RISC-V CPUs by executing instruction sequences from user space across multiple CPUs and comparing their architectural results.

RISCVuzz's design targets user-exploitable architectural vulnerabilities in closed-source RISC-V CPUs without requiring source code, golden models, hardware changes, or privileged execution. It uses a server to generate test cases and coordinate multiple RISC-V CPU clients; each client receives an instruction sequence and input, runs it, and reports architectural state such as register values and changed memory contents. The framework emphasizes testing deterministic architectural effects, because nondeterministic behavior such as performance-counter values or operating-system-controlled memory mappings complicates comparison. RISCVuzz discovers most bugs and vulnerabilities within seconds of fuzzing.

Challenges

Evidence from RISCVuzz identifies several challenges in discovering architectural CPU vulnerabilities:

1. Instruction-sequence generation: the search space is large, and undocumented instructions may be relevant, so testing cannot rely solely on known instruction models.
2. Nondeterministic effects: comparing architectural behavior requires controlling the state that influences instruction results, but post-silicon testing cannot reset or fully control the CPU and operating-system environment like RTL fuzzing can.
3. Closed-source analysis: many commercial CPUs are closed-source, which hinders vulnerability analysis and motivates black-box, post-silicon methods.

Mitigations and disclosures

Mitigations identified by RISCVuzz are limited:

• For vector-extension bugs such as GhostWrite, the only mitigation is disabling the vector extension, which breaks applications using it and incurs up to 77% overhead in rvv-bench benchmarks.
• For the C906 CPU-halting bug, no mitigation exists because the responsible vendor extension cannot be disabled.
• Scaleway reproduced the GhostWrite findings and is rolling out kernel patches that disable the vector extension on its C910-based bare-metal instances.
• T-Head acknowledged and reproduced GhostWrite and the C906 CPU-halting sequence, but had not responded to the C908 CPU-halting instructions at the time of reporting.
• RISCVuzz also reported a segmentation fault in the latest version of QEMU.

Insights on RISC-V CPU ecosystem

RISCVuzz's findings provide broader insights into the state of hardware RISC-V CPUs: vendor extensions and rushed implementations of non-finalized extensions lead not only to bugs but to exploitable security vulnerabilities that are difficult to mitigate. The base instruction set is tested significantly better than complex extensions such as the vector extension. Even for open-source cores such as the C910, the hardware implementation differs from the released source.

RISC-V context

RISC-V is an open instruction set architecture (ISA) developed by the RISC-V foundation. The RISC-V ISA consists of a core instruction set that must be implemented by all RISC-V CPUs and extensions that can be implemented as needed (e.g., the vector extension). RISC-V systems commonly use privilege levels: User mode for unprivileged applications, Supervisor mode for operating systems, and Machine mode for full hardware control and low-level operations. Access to control/status registers and privileged instructions depends on the current privilege level. In this setting, user-triggerable architectural bugs are particularly security-relevant because they cross the boundary between unprivileged execution and privileged system state.