GHSA-3rjw-m598-pq24: Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set

Summary The aarch64 implementations of Cmov and CmovEq seem to assume that the high bits when loading a value of size smaller than a register into a register are zero-extended. However, this is not the case and these bits are unspecified. This can result in a left.cmovz(&right, condition) not moving right into left, even if condition == 0. Details The Rust reference for inline assembly states that: If a value is of a smaller size than the register it is allocated in then the upper bits of that register will have an undefined value for inputs [..]. Reference If the high bits [8..] of the selector loaded into a register in the Cmov implementation or the high bits [16..] of self or other for CmovEq (specifically the implementation for u16 and i16) are set, the inline asm compares will produce a different result than the Rust code expects based on the narrow types. In other words, the following assert fails, even though condition as u8 is zero: let condition: u32 = black_box(1 << 8); let mut left = 1; let right = 2; left.cmovz(&right, condition as u8); assert_eq!(left, right); Because the ninth bit is set in the original variable, this bit is also set when the truncated condition is loaded into the input register for the cmp, causing the csel to select the wrong value. The problematic code is located in cmov/src/backends/aarch64.rs here for Cmov and here for CmovEq. The following function: #[unsafe(no_mangle)] pub fn cmovz_wrong_output(left: &mut i32, right: i32, condition: u32) { left.cmovz(&right, condition as u8); } produces the assembly: cmovz_wr