This report was found with an automated fuzzing/emulation-differential tool and manually triaged against QEMU master c513597761d6fc06690b5b7cf10dfb7ab05815d0. The reproducer and expected outcomes were independently validated before submission. ## Host environment - Operating system: Linux x86_64 Docker execution plane. - OS/kernel version: Linux container; no guest kernel is involved because this uses linux-user QEMU. - Architecture: x86_64 host running RISC-V linux-user QEMU. - QEMU flavor: qemu-riscv32 and qemu-riscv64. - QEMU version: qemu-riscv32 11.0.90 built from 5ef0ecc5942ee07bb581cc96a97bbfc0fdf4005c for the runtime matrix; current upstream source c513597761d6fc06690b5b7cf10dfb7ab05815d0 was checked separately. - QEMU command line: ```bash qemu-riscv32 -cpu rv32,xventanacondops=true ./xventana-maskc.elf qemu-riscv32 -cpu rv32,xventanacondops=true ./xventana-maskcn.elf ``` ## Emulated/Virtualized environment - Operating system: statically linked Linux ELF under QEMU linux-user. - OS/kernel version: no guest kernel; the witnesses execute directly in linux-user mode. - Architecture: RISC-V RV32 for the affected cases and RV64 for the positive controls. ## Description of problem `target/riscv/XVentanaCondOps.decode` classifies `vt.maskc` and `vt.maskcn` under the RV64 Custom-3 Extension, but their translators do not enforce the XLEN requirement. As a result, an RV32 CPU accepts these encodings when `xventanacondops=true`, even though they must remain illegal on RV32. The affected encodings are `0x0053647b` (`vt.maskc s0, t1, t0`) and `0x0053747b` (`vt.maskcn s0, t1, t0`). The `vt.maskc` witness exits 0 only if retirement writes `s0=t1`, and the `vt.maskcn` witness exits 0 only if retirement writes `s0=0`. With the extension disabled, both RV32 witnesses exit 132 as expected. With `xventanacondops=true`, the baseline RV32 build exits 0 for both witnesses; the expected result is exit 132 because the encodings are RV64-only. A patched build changes both RV32-enabled cases to exit 132 and keeps the RV64-enabled controls at exit 0. The root cause is that `trans_vt_maskc()` and `trans_vt_maskcn()` in `target/riscv/tcg/insn_trans/trans_xventanacondops.c.inc` call `gen_logic(...)` without `REQUIRE_64_OR_128BIT(ctx)` or an equivalent XLEN gate. The minimal fix is to add `REQUIRE_64_OR_128BIT(ctx);` to both translators. This is a legality-only fix and does not claim to validate other XVentanaCondOps functional semantics. ## Steps to reproduce 1. Build the two static RV32 Linux witnesses with a RISC-V cross compiler; each witness contains the raw instruction word listed above and exits 0 only when the instruction retires with the expected architectural effect. 2. Run `qemu-riscv32 -cpu rv32,xventanacondops=true ./xventana-maskc.elf`; the baseline exits 0, while the expected result is exit 132. 3. Run `qemu-riscv32 -cpu rv32,xventanacondops=true ./xventana-maskcn.elf`; the baseline exits 0, while the expected result is exit 132. 4. Run both witnesses with `-cpu rv32` to observe the expected exit 132, and run RV64 controls with `xventanacondops=true` to observe exit 0. ## Additional information The runtime matrix was collected from a clean upstream QEMU build at 5ef0ecc5942ee07bb581cc96a97bbfc0fdf4005c. Source review against current upstream c513597761d6fc06690b5b7cf10dfb7ab05815d0 still finds the missing XLEN gates, and the proposed patch applies cleanly there. I am not claiming a fresh runtime matrix for c513597761d6fc06690b5b7cf10dfb7ab05815d0. A read-only search of the QEMU GitLab issue tracker on 2026-09-03 found no matching issue for `xventana`, `xventanacondops`, `XVentanaCondOps`, `vt.maskc`, or `vt.maskcn`. This report has no security implications and does not require confidential handling. The related patch will be sent to qemu-devel according to QEMU's patch submission workflow; it is intentionally not attached to this issue.