{"id":"CVE-2026-50185","aliases":["DEBIAN-CVE-2026-50185","EUVD-2026-45254","GHSA-3rjw-m598-pq24","RHSA-2026:42923","UBUNTU-CVE-2026-50185"],"status":"published","title":"RustCrypto Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","severity":{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00157,"percentile":0.04888,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-758"],"published":"2026-07-02T17:18:11Z","modified":"2026-10-28T02:30:28Z","fixes":[{"ecosystem":"crates.io","package":"cmov","fixed_in":["0.5.4"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"rust-cmov","fixed_in":["0.5.4-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"cmov","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.1"},{"fixed":"0.5.4"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"rust-cmov","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.5.4-1"}]}],"versions":["0.5.3-1"]},{"source":"osv","ecosystem":"crates.io","package":"cmov","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.1"},{"fixed":"0.5.4"}]}]},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"cargo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"clippy","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-analyzer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-debugger-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-doc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-gdb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-lldb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-src","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-aarch64-unknown-none-softfloat","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-aarch64-unknown-uefi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-i686-pc-windows-gnu","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-wasm32-unknown-unknown","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-wasm32-wasip1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-x86_64-pc-windows-gnu","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-x86_64-unknown-none","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rust-std-static-x86_64-unknown-uefi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rustfmt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:1.97.1-1.1.hum1"}]}],"bundled":2},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"rust-cmov","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.5.3-1","0.5.4-1"]}],"products":[{"vendor":"rustcrypto","product":"cmov"},{"vendor":"rustcrypto","product":"utils"}],"references":[{"url":"https://github.com/RustCrypto/utils/security/advisories/GHSA-3rjw-m598-pq24","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web","article","report"]},{"url":"https://github.com/RustCrypto/utils/commit/dba6c355c9f241e3726d5ec2a68f9f3b519f6063","tags":["x_refsource_MISC","Patch","fix","article"]},{"url":"https://github.com/RustCrypto/utils/releases/tag/cmov-v0.5.4","tags":["x_refsource_MISC","Product","web","article"]},{"url":"https://github.com/advisories/GHSA-3rjw-m598-pq24"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/50xxx/CVE-2026-50185.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-50185","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-50185","tags":["advisory"]},{"url":"https://github.com/RustCrypto/utils","tags":["package"]},{"url":"https://access.redhat.com/errata/RHSA-2026:42923","tags":["advisory"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-50185","tags":["report"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-5223","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_42923.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2481158","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-5223","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-5223","tags":["advisory"]},{"url":"https://blog.rust-lang.org/2026/05/25/cve-2026-5223/","tags":["article"]},{"url":"https://github.com/rust-lang/cargo/pull/17031","tags":["article"]},{"url":"https://groups.google.com/g/rustlang-security-announcements/c/IB74S7Yksg8","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2501836","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-50185","tags":["advisory","report"]},{"url":"https://ubuntu.com/security/CVE-2026-50185","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-50185","title":"RustCrypto Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T18:35:02.078Z","modified":"2026-07-20T19:24:54.587Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna"}],"cwes":["CWE-758"],"updated_at":"2026-11-02T14:20:08.734143Z"}],"euvd":[{"id":"EUVD-2026-45254","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T18:35:02Z","modified":"2026-07-20T19:24:54Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"updated_at":"2026-11-02T18:19:47.959089Z"}],"ghsa":[{"id":"GHSA-3rjw-m598-pq24","title":"Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set ","description":"### Summary\n\nThe 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(\u0026right, condition)` not moving `right` into `left`, even if `condition == 0`. \n\n### Details\n\nThe Rust reference for inline assembly states that:\n\u003e 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](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.register-operands.smaller-value)\n\nIf 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.\n\nIn other words, the following assert fails, even though `condition as u8` is zero:\n```rust\nlet condition: u32 = black_box(1 \u003c\u003c 8);\nlet mut left = 1;\nlet right = 2;\nleft.cmovz(\u0026right, condition as u8);\nassert_eq!(left, right);\n```\nBecause 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.\n\nThe problematic code is located in `cmov/src/backends/aarch64.rs` [here for Cmov](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/backends/aarch64.rs#L4-L19) and [here for CmovEq](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/backends/aarch64.rs#L60-L72).\n\nThe following function:\n```rust\n#[unsafe(no_mangle)]\npub fn cmovz_wrong_output(left: \u0026mut i32, right: i32, condition: u32) {\n    left.cmovz(\u0026right, condition as u8);\n}\n```\nproduces the assembly:\n```asm\ncmovz_wrong_output:\n\t.cfi_startproc\n\tldr w8, [x0]\n\t//APP\n\tcmp w2, #0\n\tcsel w8, w1, w8, eq\n\t//NO_APP\n\tstr w8, [x0]\n\tret\n```\n\nwhich compares the 32-bits of the condition value against 0, instead of the intended 8.\n\nSimilarly, the following function using `cmoveq`\n```rust\n#[unsafe(no_mangle)]\npub fn cmoveq_wrong_output(left: u32, right: u32, input: u8, output: \u0026mut u8) {\n    (left as u16).cmoveq(\u0026(right as u16), input, output);\n}\n```\ncompiles to:\n```asm\ncmoveq_wrong_output:\n\t.cfi_startproc\n\tldrb w8, [x3]\n\tand w9, w2, #0xff\n\t//APP\n\teor w10, w0, w1\n\tcmp w10, #0\n\tcsel w8, w9, w8, eq\n\t//NO_APP\n\tstrb w8, [x3]\n\tret\n```\nwhere 32 bits of left and right are compared instead of 16. The same happens for `i16`.\n\nFor CmovEq, it seems the `u8/i8` impls are not affected, as they are calling `u16::from` in [the implementation](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/lib.rs#L119) which causes the upper bits to be masked out.\n\n### PoC\n\nThe following two test cases fail on `aarch64-unknown-linux-gnu` when compiled with `--release` (the cmovz one even in debug) emulated with qemu.\n\n```\n\u003e rustc --version\nrustc 1.94.0 (4a4ef493e 2026-03-02)\n```\n\n```rust\n#[cfg(test)]\nmod tests {\n    use core::hint::black_box;\n\n    use cmov::{Cmov, CmovEq};\n\n    #[test]\n    fn cmovz_wrong_output() {\n        // The black box is necessary here, as otherwise the compiler will \n        // provide a constant 0 to the csel\n        let condition: u32 = black_box(1 \u003c\u003c 8);\n        let mut left = 1;\n        let right = 2;\n        // I added this debug_assert as a sanity check, but funnily it causes\n        // the wrong cmov behavior in debug as well (as opposed to only in release mode without the debug_assert)\n        debug_assert_eq!(0, condition as u8);\n        left.cmovz(\u0026right, condition as u8);\n        assert_eq!(left, right);\n    }\n\n    #[test]\n    fn cmoveq_wrong_output() {\n        let input = 1;\n        let mut output = 0;\n        let left: u32 = black_box(1 \u003c\u003c 16);\n        let right: u32 = black_box(1 \u003c\u003c 17);\n        // asserting in release mode here would hide the bug, the debug_assert_eq is\n        // a sanity check that these values SHOULD be equal\n        debug_assert_eq!(left as u16, right as u16);\n        (left as u16).cmoveq(\u0026(right as u16), input, \u0026mut output);\n        assert_eq!(input, output);\n    }\n}\n```\n\n### Impact\n\nUnder specific circumstances, this issue can cause `Cmov/CmovEq` to produce incorrect output on `aarch64`. However, whether this bug can actually manifest depends on the surrounding code that calls the relevant impls. In the PoC, a narrowing cast is required, which masks out the set bits from Rust's point of view, but which are then used in the inline assembly. \n\n### Additional Finding\n\nPR [#1299](https://github.com/RustCrypto/utils/pull/1299) fixed a different bug in the aarch64 backend but introduced a small error. The `csel!` macro expect a `cmp` expression as its first argument which is never used. The compare is always `\"cmp {0:w}, 0\",` even for `csel64!`, which intends to use `cmp {0:x}, 0`. Given the bug described above, this oversight actually reduces its impact slightly, as only the bits in position`[8..32]` can cause issues,  even for those impls that use `csel64!`.","status":"published","published":"2026-07-02T17:18:11Z","modified":"2026-07-02T17:18:12Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-758"],"updated_at":"2026-11-02T14:40:37.437888Z"}],"nvd":[{"id":"CVE-2026-50185","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T19:17:16.37Z","modified":"2026-10-24T20:10:00.137Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low","assessor":"secondary"},{"version":"3.1","score":3.3,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"primary"}],"cwes":["CWE-758"],"updated_at":"2026-11-02T14:12:30.250437Z"}],"osv":[{"id":"CVE-2026-50185","title":"RustCrypto Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T18:35:02.078Z","modified":"2026-10-28T02:30:28.211734015Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-758"],"updated_at":"2026-11-02T15:45:07.431113Z"},{"id":"DEBIAN-CVE-2026-50185","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T19:17:16.37Z","modified":"2026-10-25T09:47:27.711736736Z","cvss":[{"version":"3.1","score":3.3,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:45:56.877408Z"},{"id":"GHSA-3rjw-m598-pq24","title":"Cmov/CmovEq on aarch64 can produce wrong results if high-bits of registers are set ","description":"### Summary\n\nThe 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(\u0026right, condition)` not moving `right` into `left`, even if `condition == 0`. \n\n### Details\n\nThe Rust reference for inline assembly states that:\n\u003e 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](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.register-operands.smaller-value)\n\nIf 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.\n\nIn other words, the following assert fails, even though `condition as u8` is zero:\n```rust\nlet condition: u32 = black_box(1 \u003c\u003c 8);\nlet mut left = 1;\nlet right = 2;\nleft.cmovz(\u0026right, condition as u8);\nassert_eq!(left, right);\n```\nBecause 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.\n\nThe problematic code is located in `cmov/src/backends/aarch64.rs` [here for Cmov](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/backends/aarch64.rs#L4-L19) and [here for CmovEq](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/backends/aarch64.rs#L60-L72).\n\nThe following function:\n```rust\n#[unsafe(no_mangle)]\npub fn cmovz_wrong_output(left: \u0026mut i32, right: i32, condition: u32) {\n    left.cmovz(\u0026right, condition as u8);\n}\n```\nproduces the assembly:\n```asm\ncmovz_wrong_output:\n\t.cfi_startproc\n\tldr w8, [x0]\n\t//APP\n\tcmp w2, #0\n\tcsel w8, w1, w8, eq\n\t//NO_APP\n\tstr w8, [x0]\n\tret\n```\n\nwhich compares the 32-bits of the condition value against 0, instead of the intended 8.\n\nSimilarly, the following function using `cmoveq`\n```rust\n#[unsafe(no_mangle)]\npub fn cmoveq_wrong_output(left: u32, right: u32, input: u8, output: \u0026mut u8) {\n    (left as u16).cmoveq(\u0026(right as u16), input, output);\n}\n```\ncompiles to:\n```asm\ncmoveq_wrong_output:\n\t.cfi_startproc\n\tldrb w8, [x3]\n\tand w9, w2, #0xff\n\t//APP\n\teor w10, w0, w1\n\tcmp w10, #0\n\tcsel w8, w9, w8, eq\n\t//NO_APP\n\tstrb w8, [x3]\n\tret\n```\nwhere 32 bits of left and right are compared instead of 16. The same happens for `i16`.\n\nFor CmovEq, it seems the `u8/i8` impls are not affected, as they are calling `u16::from` in [the implementation](https://github.com/RustCrypto/utils/blob/dad5e3b9e66d929e86144fe7c8f25371892e35f3/cmov/src/lib.rs#L119) which causes the upper bits to be masked out.\n\n### PoC\n\nThe following two test cases fail on `aarch64-unknown-linux-gnu` when compiled with `--release` (the cmovz one even in debug) emulated with qemu.\n\n```\n\u003e rustc --version\nrustc 1.94.0 (4a4ef493e 2026-03-02)\n```\n\n```rust\n#[cfg(test)]\nmod tests {\n    use core::hint::black_box;\n\n    use cmov::{Cmov, CmovEq};\n\n    #[test]\n    fn cmovz_wrong_output() {\n        // The black box is necessary here, as otherwise the compiler will \n        // provide a constant 0 to the csel\n        let condition: u32 = black_box(1 \u003c\u003c 8);\n        let mut left = 1;\n        let right = 2;\n        // I added this debug_assert as a sanity check, but funnily it causes\n        // the wrong cmov behavior in debug as well (as opposed to only in release mode without the debug_assert)\n        debug_assert_eq!(0, condition as u8);\n        left.cmovz(\u0026right, condition as u8);\n        assert_eq!(left, right);\n    }\n\n    #[test]\n    fn cmoveq_wrong_output() {\n        let input = 1;\n        let mut output = 0;\n        let left: u32 = black_box(1 \u003c\u003c 16);\n        let right: u32 = black_box(1 \u003c\u003c 17);\n        // asserting in release mode here would hide the bug, the debug_assert_eq is\n        // a sanity check that these values SHOULD be equal\n        debug_assert_eq!(left as u16, right as u16);\n        (left as u16).cmoveq(\u0026(right as u16), input, \u0026mut output);\n        assert_eq!(input, output);\n    }\n}\n```\n\n### Impact\n\nUnder specific circumstances, this issue can cause `Cmov/CmovEq` to produce incorrect output on `aarch64`. However, whether this bug can actually manifest depends on the surrounding code that calls the relevant impls. In the PoC, a narrowing cast is required, which masks out the set bits from Rust's point of view, but which are then used in the inline assembly. \n\n### Additional Finding\n\nPR [#1299](https://github.com/RustCrypto/utils/pull/1299) fixed a different bug in the aarch64 backend but introduced a small error. The `csel!` macro expect a `cmp` expression as its first argument which is never used. The compare is always `\"cmp {0:w}, 0\",` even for `csel64!`, which intends to use `cmp {0:x}, 0`. Given the bug described above, this oversight actually reduces its impact slightly, as only the bits in position`[8..32]` can cause issues,  even for those impls that use `csel64!`.","status":"published","published":"2026-07-02T17:18:11Z","modified":"2026-09-10T03:51:10.250390903Z","cvss":[{"version":"4.0","score":5.5,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P","level":"medium"}],"cwes":["CWE-758"],"updated_at":"2026-11-02T15:46:36.092962Z"},{"id":"RHSA-2026:42923","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update","status":"published","published":"2026-07-28T10:13:06Z","modified":"2026-10-06T10:31:26.67671207Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:53:20.491441Z"},{"id":"UBUNTU-CVE-2026-50185","description":"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. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(\u0026right, condition) to produce incorrect output. This issue is fixed in version 0.5.4.","status":"published","published":"2026-07-17T19:17:00Z","modified":"2026-10-17T12:58:32.891074342Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"},{"version":"3.1","score":3.3,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T16:56:33.391918Z"}]}}