0xMiden/miden-vm

UniqueNodes is the serialized form of a partial SMT. Its writer emits a canonical shape: levels come out in ascending depth order (the BTreeMap order, source), each position appears once, and a position is either a leaf or a value-only entry. read_from (source) checks none of that. Three payloads that the writer can never emit decode without error: A position repeated inside one level. The reader inserts into a map, so the last value silently replaces the first. Levels in any depth order. The same set of nodes then has more than one valid encoding. A position listed in both leaves and value_only_leaves. get_leaf_hash prefers the leaf (through .or_else), so the value-only entry cannot be reached. The wire form of a node set is therefore not unique, and the decoder can be handed a state that its own accessors resolve inconsistently. Reproduction Save the following as crates/crypto/tests/unique_nodes_wire_reader.rs, then run: cargo test -p miden-crypto --test unique_nodes_wire_reader //

SourceSpan holds the bounds of a byte range, so it assumes start <= end. Its len() returns the unsigned difference end - start (source). The wire decoder reads a source id, a start, and an end from three u32 values and stores them without comparing the two bounds (source). A payload of start = 5, end = 3 therefore decodes without complaint. Calling .len() on the result panics in a debug build with attempt to subtract with overflow, and wraps silently in a release build. No writer produces such a span from a real source range, so the payload only arrives as hand-written or corrupted bytes. The decoder takes it anyway. Reproduction Save the following as crates/debug-types/tests/span_reversed_bounds.rs, then run: cargo test -p miden-debug-types --test span_reversed_bounds //! Reproduction for: `SourceSpan` wire decoder accepts reversed bounds (`start > end`); //! the decoded value panics on `.len()`. use miden_crypto::utils::Deserializable; use miden_debug_types::SourceSpan; /// A paylo

MerkleStore::find_lone_leaf (crates/crypto/src/merkle/store/mod.rs) accepts any tree_depth <= 64, but compares children against the empty subtree roots of a depth-64 tree: const MAX_DEPTH: u8 = u64::BITS as u8; ... let empty = EmptySubtreeRoots::empty_hashes(MAX_DEPTH); ... let empty_node = empty[depth as usize + 1]; For a shallower tree no child ever equals empty_node, so the walk stops at the root with Ok(None) even when the tree has exactly one leaf. get_leaf_depth uses empty_hashes(tree_depth) and works on the same tree. Repro (depth-8 tree, single leaf at index 105) assert_eq!(store.get_leaf_depth(root, 8, 105).unwrap(), 8); store.find_lone_leaf(root, NodeIndex::root(), 8) actual: None expected: Some((NodeIndex { depth: 8, position: 105 }, [1, 1, 1, 1])) Nothing in this repo calls it anymore, so this only affects external users with trees shallower than 64. Fix is empty_hashes(tree_depth); I have it with the test above if you want it.

Direct MAST root invocations such as call.0x... accept a root as 64 hex digits. The InvocationTarget documentation calls this a hexadecimal representation of a Word, but it does not define the byte order. The parser splits the literal into four 8-byte chunks and reads each chunk with u64::from_le_bytes. This matches Word::to_hex(), since Word::as_bytes() writes each field element in little-endian order. The missing documentation makes another plausible format unsafe. Formatting the same four field elements as canonical integers gives a different string that is still valid syntax: Word elements: 0x1f92867d5acabdfd 0xece9a4eb6d0c2ae1 0x9359c1a7ae1fa54e 0x1fc16cc6ab2d94c0 Word::to_hex(): 0xfdbdca5a7d86921fe12a0c6deba4e9ec4ea51faea7c15993c0942dabc66cc11f Canonical integer hex: 0x1f92867d5acabdfdece9a4eb6d0c2ae19359c1a7ae1fa54e1fc16cc6ab2d94c0 I reproduced this on next at bb21374d070e66773a6095c251e5e760e500e297. The first string parses back to the original Word. The second string also p

Summary AdviceMap::read_from inserts entries into the map without checking for a repeated key, so a serialized advice map that carries the same key twice deserializes Ok with only the last value. MastForestWireView::new rejects the same bytes ("duplicate advice key in wire payload"), so the wire view and the deserializing readers disagree on identical payloads, and the deserializing readers lose data silently. Where core/src/advice/map.rs, impl Deserializable for AdviceMap: map.insert(key, Arc::from(values)) in the read loop, no duplicate check. Reached from decode_from_reader_inner (core/src/mast/serialization/mod.rs), which backs both MastForest::read_from and UntrustedMastForest::read_from_bytes; UntrustedMastForest::validate() does not re-check the advice section. Package::read_from and AdviceInputs::read_from go through the same code. Contrast: WireAdviceMapView::new (core/src/mast/serialization/view.rs) rejects a repeated key. Every other list section of the wire format (externa