starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2012] Debug assert triggered: record types do not match, DNSKEY <> Some(Unknown(48)) #850

New issue

Closed

opened 2026-03-16 00:32:53 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 00:32:53 +03:00

Owner

Originally created by @oherrala on GitHub (Aug 31, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2012

Describe the bug

While fuzzing the run crashed with

thread '<unnamed>' panicked at /Users/oherrala/rust/trust-dns/crates/proto/src/rr/resource.rs:537:9:
record types do not match, DNSKEY <> Some(Unknown(48))

The debug assert that triggered is this:

github.com/bluejekyll/trust-dns@a0523a5823/crates/proto/src/rr/resource.rs (L537C1-L546C11)

To Reproduce
Steps to reproduce the behavior:

This can be triggered with running the fuzz/fuzz_targets/message.rs fuzzer.

The following binary message should be put to fuzz/artifacts/message/crash-35f0d2e1df3405825743cfaf42bccd0c84c4b219:

Output of `std::fmt::Debug`:
        [48, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 1, 0, 0, 48, 0, 1, 0, 1, 0, 2, 0, 1, 0]

and then run:

% cd fuzz
% cargo +nightly fuzz run message artifacts/message/crash-35f0d2e1df3405825743cfaf42bccd0c84c4b219

Expected behavior

The debug assert is probably there to catch some erroneous condition? This is one way to trigger that error condition.

System:

OS: macOS
Architecture: arm65
Version: git main (a0523a5823)
rustc version: [e.g. 1.72.0]

Originally created by @oherrala on GitHub (Aug 31, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2012 **Describe the bug** While fuzzing the run crashed with ``` thread '<unnamed>' panicked at /Users/oherrala/rust/trust-dns/crates/proto/src/rr/resource.rs:537:9: record types do not match, DNSKEY <> Some(Unknown(48)) ``` The debug assert that triggered is this: https://github.com/bluejekyll/trust-dns/blob/a0523a5823bbad6732cb9b5ca15d61e0d6eaa2e0/crates/proto/src/rr/resource.rs#L537C1-L546C11 **To Reproduce** Steps to reproduce the behavior: This can be triggered with running the `fuzz/fuzz_targets/message.rs` fuzzer. The following binary message should be put to `fuzz/artifacts/message/crash-35f0d2e1df3405825743cfaf42bccd0c84c4b219`: ``` Output of `std::fmt::Debug`: [48, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 1, 0, 0, 48, 0, 1, 0, 1, 0, 2, 0, 1, 0] ``` and then run: ```console % cd fuzz % cargo +nightly fuzz run message artifacts/message/crash-35f0d2e1df3405825743cfaf42bccd0c84c4b219 ``` **Expected behavior** The debug assert is probably there to catch some erroneous condition? This is one way to trigger that error condition. **System:** - OS: macOS - Architecture: arm65 - Version: git main (a0523a5823bbad6732cb9b5ca15d61e0d6eaa2e0) - rustc version: [e.g. 1.72.0]

kerem

2026-03-16 00:32:53 +03:00

closed this issue
added the
bug

trust

crate:proto
labels

kerem commented

2026-03-16 00:33:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 3, 2023):

looks like something is going on in regards to encoding and decoding. There are some options in DNSKEY that are no longer relevant and I'm guessing that this object has enabled something deprecated and the decoder zeros out the field while it might be possible to create it initially...

@bluejekyll commented on GitHub (Sep 3, 2023): looks like something is going on in regards to encoding and decoding. There are some options in DNSKEY that are no longer relevant and I'm guessing that this object has enabled something deprecated and the decoder zeros out the field while it might be possible to create it initially...

kerem commented

2026-03-16 00:33:15 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 19, 2023):

I may have fixed this in #2025 as it looks like the same assertion that's failing.

@bluejekyll commented on GitHub (Sep 19, 2023): I may have fixed this in #2025 as it looks like the same assertion that's failing.

kerem commented

2026-03-16 00:33:20 +03:00

Author

Owner

@oherrala commented on GitHub (Sep 20, 2023):

@bluejekyll This panic is gone with #2025, but fuzzer immediately found panic on another place. I'll make a separate issue out from it.

@oherrala commented on GitHub (Sep 20, 2023): @bluejekyll This panic is gone with #2025, but fuzzer immediately found panic on another place. I'll make a separate issue out from it.

kerem commented

2026-03-16 00:33:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 20, 2023):

fixed in #2025

@bluejekyll commented on GitHub (Sep 20, 2023): fixed in #2025