riscv64: shift instructions can behave wrong

[Cskorpion]

Description

The RISCV64 ISA specifications say that the shift operations:

• sra, srl, sll use the lowest 6 bits of rd2
• sraw, srlw, sllw use the lowest 5 bits of rd2
  as amount to shift by.

(Can be found in the RISCV unprivileged manual, chapter 4.2.1. Integer Register-Immediate Instructions)

In VEX/priv/guest_riscv64_toIR.c lines 1536-1586 and lines 1712-1740, these shift instructions are decoded, but the lowest 8 bits of rs2 are taken as parameter for the shift.
This can result in shifts by more than 63 for sra, srl, sll and more than 31 for raw, srlw, sllw.

Steps to reproduce the bug

reproducer: https://github.com/Cskorpion/angr-shift-reproducer

Environment

angr environment report

Date: 2025-09-05 17:26:42.930274
!!! running in global environment. Are you sure? !!!
Platform: linux-x86_64
Python version: 3.11.13 (main, Jun 5 2025, 13:12:00) [GCC 11.2.0]
######## angr #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/angr/init.py
Pip version 9.2.173
Couldn't find git info
######## ailment #########
An error occurred importing ailment: 'NoneType' object has no attribute 'origin'
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/angr/init.py
Pip version not found!
Couldn't find git info
######## cle #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/cle/init.py
Pip version 9.2.173
Couldn't find git info
######## pyvex #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/pyvex/init.py
Pip version 9.2.173
Couldn't find git info
######## claripy #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/claripy/init.py
Pip version 9.2.173
Couldn't find git info
######## archinfo #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/archinfo/init.py
Pip version 9.2.173
Couldn't find git info
######## z3 #########
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/z3/init.py
Pip version 4.13.0.0
Couldn't find git info
######## unicorn #########
An error occurred importing unicorn: 'NoneType' object has no attribute 'origin'
Python found it in /home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/z3/init.py
Pip version not found!
Couldn't find git info
######### Native Module Info ##########
angr: <CDLL '/home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/angr/unicornlib.so', handle 151e12b0 at 0x7fcda4a0a4d0>
unicorn: NOT FOUND
pyvex: <cffi.api._make_ffi_library..FFILibrary object at 0x7fcda7488c10>
z3: <CDLL '/home/christophj/anaconda3/envs/angr2/lib/python3.11/site-packages/z3/lib/libz3.so', handle 148e3950 at 0x7fcda91e5050>

Additional context

Bug is also reported at vex https://bugs.kde.org/show_bug.cgi?id=509157

[rhelmot]

Do you know if they've fixed this in upstream valgrind?

[rhelmot]

I'm so sorry, I didn't read the relevant part of your post. I don't think any of us have the cycles available to fix this, but we'll gladly take a PR.

[cfbolz]

@Cskorpion and I have discussed this a bit more (we are collaborating on this). It's not completely clear to us any more, where the bug is. The real problem imo is that the semantics of the VEX shift instructions when the shift amount is too large is not clearly defined anywhere, and angr and various parts of the VEX code base interpret it differently.

Specifically, how should VEX shift instructions behave if the shift amount is larger than log2 of the first argument size? Is the shift amount implicitly masked and the upper bits ignored (this interpretation is what the VEX RISC-V frontend and instruction selection uses right now)? Or should the result be e.g. 0/-1 in the case of an arithmetic right shift with too large shift amount (this is how angr and some other VEX architectures seem to interpret the semantics)?

For some other ISAs that VEX supports (we checked x86-64 and aarch64) this isn't a problem, because they simply circumvent the question by introducing explicitly the masks that are needed.

I've added a comment about this question to the valgrind bug. Maybe they'll clarify. If not, we can still go for the approach of Christoph's PR and fix the problem in the RISC-V frontend (which would bring it more in line with the x86-64 and aarch64 frontends).

[rhelmot]

Very interesting. I would assume that the semantics of the IR shift operation are "saturating", but I suppose the opposite is possible.

Assuming we already know what the RISC-V instruction semantics are supposed to be, my preference would be to address any disparity between them in the lifter and maintain angr's conception of the saturating shift operation. If the valgrind people come back and say that the IR shift is meant to be masked (not saturating), I would honestly prefer to diverge from their opinions :)

[cfbolz]

yeah, that approach makes perfect sense to me! and it seems that the common VEX frontends use the saturating semantics anyway (they add the masks), so RISC-V is the odd one.

(background: @Cskorpion and I are comparing the SMT formulas we get from angr against SMT formulas we extract from the Sail RISC-V semantics to try to find bugs in either. We'll also submit patches for the problems we find, if we can.)