RustCrypto Utilities cmov: thumbv6m-none-eabi compiler emits non-constant time assembly when using cmovnz

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS 4.0

8.9 · CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N · score source

EPSS

• CVE-2026-23519: 0.56% estimated exploitation activity in the next 30 days; percentile 46.52 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

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, an LLVM optimisation pass is detecting that bitnz is returning 0 or 1, that can be interpreted as a boolean. This intermediate value is not masked by a call to blackbox and thus the subsequent .wrappingsub(1) 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: The resulting assembly emitted (shown using cargo asm --release --target thumbv6m-none-eabi that uses cargo-show-asm): <details <summaryCollapsed assembly</summary </details The non-constant time assembly is: Impact The exact impact is unclear, especially since cmov clearly warns users…

Published by the source

15 Jan 2026, 18:17 UTC

Last modified by the source

23 Jan 2026, 21:46 UTC

Source last checked

26 Oct 2026, 15:39 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-2gqc-6j2q-83qp

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2026-23519

Advisory: RustCrypto Utilities cmov: `thumbv6m-none-eabi` compiler emits non-constant time assembly when using `cmovnz`
IDs: CVE-2026-23519, GHSA-2gqc-6j2q-83qp
Record: https://patchnext.com/advisories/cve-2026-23519 (revision 1, source checked 26 Oct 2026, 15:39 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: High (CVSS 8.9)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: cmov 0.4.4. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io cmov: affected < 0.4.4; fixed in 0.4.4

## Suggested inspection (read-only)
- crates.io cmov: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on cmov.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-2gqc-6j2q-83qp (GitHub-reviewed advisory GHSA-2gqc-6j2q-83qp lists affected ranges: crates.io cmov >=0 <0.4.4)

Commands are suggestions: review each one before running it.