Overview

FENCE.I is a RISC-V instruction discussed in the hardware-fuzzing evidence in the context of instruction-cache invalidation and instruction-stream behavior. In a TheHuzz-reported scenario, Spike identified the FENCE.I instruction and, when it did not recognize an extension, fell back to flushing the entire cache; by contrast, Ariane failed to recognize FENCE.I and marked it as an illegal instruction, which the paper describes as non-compliant with the RISC-V ISA.[C1]

Verification and security relevance

The TheHuzz evidence describes a divergence between Spike and Ariane after code invalidation and later execution of the original executable region. In Spike, the new instructions were present and executed as expected. In Ariane, old instructions remained because FENCE.I was not recognized correctly. The paper states that this allowed an attacker to replace bounds checks with effective no-ops, inject a stack-overflow vulnerability, and gain arbitrary code execution.[C2]

CVA6 fuzzing benchmark context

A later ARCUS survey table lists “V1: Incorrect decoding of FENCE.I instruction” under “Vulnerabilities in CVA6” and maps it to CWE-440. The same table reports test-case counts for multiple hardware-fuzzing techniques or baselines, including TheHuzz, HypFuzz, PSOFuzz, and MABFuzz, indicating that this FENCE.I decoding issue is used as a benchmark vulnerability in comparative hardware-fuzzing evaluation.[C3]

Notes

The current evidence supports describing FENCE.I mainly through observed implementation behavior and benchmarked vulnerabilities. It does not provide a full architectural specification of the instruction encoding or its formal ISA semantics.