anweiss / cddl

Concise data definition language (RFC 8610) implementation and JSON and CBOR validator in Rust
https://cddl.anweiss.tech
MIT License
91 stars 13 forks source link

Crash when making a choice between fixed array and map with int keys #197

Closed dennwc closed 1 year ago

dennwc commented 1 year ago

I'm trying to validate the following CDDL schema:

Ref = nil / refShort / refFull

blobSize = uint
hashID = uint .lt 23
hashName = text
hashDigest = bytes

refShort = [ blobSize, hashID, hashDigest ]
refFull = { 1: blobSize, 2: hashName, 3: hashDigest }

against the following CBOR test data (sample 1).

Sample 1 (array)

Data in hex

8303025820ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

CBOR structure

[3, 2, h'BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD']

CBOR encoding

83                                      # array(3)
   03                                   # unsigned(3)
   02                                   # unsigned(2)
   58 20                                # bytes(32)
      BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD

In theory, this data should match the refShort type. However it currently leads to a crash.

Crash details

Version: cddl 0.9.1

Stack trace ``` [INFO] Root type for validation: Ref thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/validator/cbor.rs:3372:23 stack backtrace: 0: 0x55ee6fd65732 - std::backtrace_rs::backtrace::libunwind::trace::h9135f25bc195152c at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x55ee6fd65732 - std::backtrace_rs::backtrace::trace_unsynchronized::h015ee85be510df51 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x55ee6fd65732 - std::sys_common::backtrace::_print_fmt::h5fad03caa9652a2c at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:66:5 3: 0x55ee6fd65732 - ::fmt::h2b42ca28d244e5c7 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:45:22 4: 0x55ee6fccdaac - core::fmt::write::h401e827d053130ed at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/fmt/mod.rs:1198:17 5: 0x55ee6fd45e20 - std::io::Write::write_fmt::hffec93268f5cde32 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/io/mod.rs:1672:15 6: 0x55ee6fd661a3 - std::sys_common::backtrace::_print::h180c4c706ee1d3fb at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:48:5 7: 0x55ee6fd661a3 - std::sys_common::backtrace::print::hd0c35d18765761c9 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:35:9 8: 0x55ee6fd661a3 - std::panicking::default_hook::{{closure}}::h1f023310983bc730 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:295:22 9: 0x55ee6fd6688d - std::panicking::default_hook::h188fec3334afd5be at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:314:9 10: 0x55ee6fd6688d - std::panicking::rust_panic_with_hook::hf26e9d4f97b40096 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:698:17 11: 0x55ee6fd6646b - std::panicking::begin_panic_handler::{{closure}}::hfab912107608087a at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:586:13 12: 0x55ee6fd66406 - std::sys_common::backtrace::__rust_end_short_backtrace::h434b685ce8d9965b at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:138:18 13: 0x55ee6fd663c2 - rust_begin_unwind at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5 14: 0x55ee6fbf1542 - core::panicking::panic_fmt::ha6dc7f2ab2479463 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14 15: 0x55ee6fbf163c - core::panicking::panic::hb3ad04c589a0e3c8 at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5 16: 0x55ee6fc12b1d - >>::visit_value::h7840d5f21197cc59 17: 0x55ee6fc81673 - cddl::visitor::walk_group_entry::hb386b0c8c89edab7 18: 0x55ee6fc137fd - >>::visit_group::h0bfb35869faade31 19: 0x55ee6fc10967 - cddl::validator::cbor::CBORValidator::validate_array_items::h64868ec22fb7c7e1 20: 0x55ee6fc1b36a - >>::visit_type2::hab70cfcda276224c 21: 0x55ee6fc17f6d - >>::visit_type::hadd37e9d85d7d2da 22: 0x55ee6fc17dc7 - >>::visit_type_rule::hef241b6b83b4d06f 23: 0x55ee6fc1b844 - >>::visit_type2::hab70cfcda276224c 24: 0x55ee6fc17f6d - >>::visit_type::hadd37e9d85d7d2da 25: 0x55ee6fc17dc7 - >>::visit_type_rule::hef241b6b83b4d06f 26: 0x55ee6fc68345 - cddl::validator::validate_cbor_from_slice::hcc6b86104ef6df0a 27: 0x55ee6fbfb7b3 - cddl::main::h7593ea401ca5b573 28: 0x55ee6fc0cd21 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd733e7fd1b0b4fbe 29: 0x55ee6fbfd1a8 - main 30: 0x7f9fcd9c1d90 - __libc_start_call_main at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16 31: 0x7f9fcd9c1e40 - __libc_start_main_impl at ./csu/../csu/libc-start.c:392:3 32: 0x55ee6fbf5a8e - _start 33: 0x0 - ```

Sample 2 (map)

If I remove the refFull type choice from the Ref, it correctly passes on the test data above, but obviously fails on the actual cases that should match refFull (below).

Data in hex

a301186402636e657703581e303132333435363738393031323334353637383930313233343536373839

CBOR structure

{1: 100, 2: "new", 3: h'303132333435363738393031323334353637383930313233343536373839'}

CBOR encoding

A3                                      # map(3)
   01                                   # unsigned(1)
   18 64                                # unsigned(100)
   02                                   # unsigned(2)
   63                                   # text(3)
      6E6577                            # "new"
   03                                   # unsigned(3)
   58 1E                                # bytes(30)
      303132333435363738393031323334353637383930313233343536373839

So I'm wondering, is my schema incorrect or it's a bug in the validation code?

anweiss commented 1 year ago

This has been fixed in #201. Please re-open if you're still having issues.