Most recent entries from all

EUVD-2026-265859

fkie_cve-2026-23519

RustCrypto CMOV provides conditional move CPU intrinsics which are guaranteed on major platforms to execute in constant-time and not be rewritten as branches by the compiler. Prior to 0.4.4, the thumbv6m-none-eabi (Cortex M0, M0+ and M1) compiler emits non-constant time assembly when using cmovnz (portable version). This vulnerability is fixed in 0.4.4.

GHSA-2gqc-6j2q-83qp — RustCrypto Utilities cmov: `thumbv6m-none-eabi` compiler emits non-constant time assembly when using `cmovnz`

Affected: crates.io: cmov

### Summary

`thumbv6m-none-eabi` (Cortex M0, M0+ and M1) compiler emits non-constant time assembly when using `cmovnz` (portable version). I did not found any other target with the same behaviour but I did not go through all targets supported by Rust.

### Details

It seems that, [during `mask` computation](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L78), an LLVM optimisation pass is detecting that [`bitnz`](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L13) is returning 0 or 1, that can be interpreted as a boolean. This intermediate value is not masked by a call to `black_box` and thus the subsequent [`.wrapping_sub(1)`](https://github.com/RustCrypto/utils/blob/9e555db060c80f4669d804f448a524a37d201b32/cmov/src/portable.rs#L78C1-L78C84) can be interpreted as a conditional bitwise conditional not.

### PoC

This is an attempt at having a minimal faulty code. In a library crate with an up-to-date `cmov` as only dependency, the content of `src/lib.rs` is:

```rust #![no_std] use cmov::Cmov;

#[inline(never)] pub fn test_ct_cmov(a: &mut u8, b: u8, c: u8) { a.cmovnz(&b, c); } ```

The resulting assembly emitted (shown using `cargo asm --release --target thumbv6m-none-eabi` that uses [`cargo-show-asm`](https://crates.io/crates/cargo-show-asm)):

<details> <summary>Collapsed assembly</summary>

```asm .section .text.not_ct::test_ct_cmov,"ax",%progbits .globl…

RUSTSEC-2026-0003 — Non-constant-time code generation on ARM32 targets

Affected: crates.io: cmov

## Summary

While the `cmov` crate has a special backend for `aarch64` which uses special CSEL instructions, on 32-bit ARM it uses a portable pure Rust fallback implementation. This implementation uses a combination of bitwise arithmetic and `core::hint::black_box` to attempt to coerce constant-time code generation out of the optimizer, but the implementation in v0.4.3 and earlier failed to do this on 32-bit ARM targets.

## Impact

Branch instructions inserted by the LLVM optimizer on 32-bit targets can be leveraged using various microarchitectural sidechannels like cache timing attacks to learn secret information that `cmov` is designed to protect.

## Details

The following assembly was emitted when using `Cmov::cmovnz`, a function which implements a conditional move when a provided value is non-zero:

```asm bne .LBB0_2 mvns r3, r3 ```

This includes a branch instruction `bne`: Branch if Not Equal.

## PoC

The following code reproduces the issue:

```rust #![no_std] use cmov::Cmov;

#[inline(never)] pub fn test_ct_cmov(a: &mut u8, b: u8, c: u8) { a.cmovnz(&b, c); } ```

## Resolution

`cmov` v0.4.4 includes a portable `black_box`-based tactical mitigation for the issue which coerced the compiler into producing the expected codegen, and additionally v0.4.5 added an `asm!` reimplementation of the problematic mask generation function for ARM32 targets which should guarantee that particular function never contains a branch on such targets.