The presented bit pattern is a reserved opcode in both RVV 1.0 and 0.7.1, in quite different ways. It is possible that in some future RVV 2.0 or 3.0 this bit p

The presented bit pattern is a reserved opcode in both RVV 1.0 and 0.7.1, in quite different ways. It is possible that in some future RVV 2.0 or 3.0 this bit pattern might represent `vse128.v` but it is at least equally possible that it won't -- there is no clear pattern In RVV 0.7.1 / XTHeadVector it is complete nonsense to call it `vse128.v`. There is no room in the width encoding for additional sizes. There isn't even an encoding for 64 bit elements. And the instruction naming style is quite different, with totally different semantics in the event that the load/store element width is different to the `vsetvl` element width: - `vse.v` Store using the element size from the `vsetvl` (i.e. just a raw bit for bit transfer) - `vsb.v` truncate elements to 8 bits while storing them - `vsh.v` truncate elements to 16 bits while storing them - `vsw.v` truncate elements to 32 bits while storing them THead has enumerated in their manual the differences from RVV draft 0.7.1. They amount to not implementing the `EDIV` feature (which is optional anyway) and they add the `vlenb` CSR. If the bit pattern used in this exploit is intended to be some THead extension then it is completely undocumented. More likely, it's just a completely accidental instruction from an undefined encoding that should simply trap. The same problem could happen equally easily with a mistake in implementation of ratified extension.