[GH-ISSUE #2353] Multiple round-trip encoding issues identified by fuzzer #968

New issue

Closed

opened 2026-03-16 01:07:49 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 01:07:49 +03:00

Owner

Originally created by @divergentdave on GitHub (Aug 13, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2353

I tried running the message fuzzer locally, and it produced some failing inputs pretty quickly. The issues I've identified thus far are:

When parsing the CAA issuer-domain-name, if \.\. appears in the input, it gets normalized to ... When this is encoded and decoded again, it fails the second time with the message "Malformed label: ".
When parsing CAA parameter values, non-ASCII bytes get incorrectly transformed into Unicode characters via char::from(), and appended to a string. When the resulting string gets encoded again, two bytes of mojibake will be written out in place of the original byte.
SVCB values for unknown keys get serialized with an extra 1-byte length prefix after the 2-byte length SvcParamValue length prefix.

These bugs, and others the fuzzer may yet find, could impact the correctness of the recursor, since it round-trips records through hickory_proto::rr::record_data::RData.

This project is set up in OSS-Fuzz, but there's a build issue preventing it from working currently. There are similar issues with other Rust projects right now, so it's likely an issue with incompatibilities between dependencies and the old nightly toolchain that OSS-Fuzz has pinned. (they're currently blocked on upgrading to a newer nightly toolchain because their coverage tooling doesn't yet support LLVM 18) This should be straightforward to fix, by downgrading dependencies before building the fuzzer, in order to get continuous fuzzer coverage going again.

Originally created by @divergentdave on GitHub (Aug 13, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2353 I tried running the `message` fuzzer locally, and it produced some failing inputs pretty quickly. The issues I've identified thus far are: - When parsing the CAA issuer-domain-name, if `\.\.` appears in the input, it gets normalized to `..`. When this is encoded and decoded again, it fails the second time with the message `"Malformed label: "`. - When parsing CAA parameter values, non-ASCII bytes get incorrectly transformed into Unicode characters via `char::from()`, and appended to a string. When the resulting string gets encoded again, two bytes of mojibake will be written out in place of the original byte. - SVCB values for unknown keys get serialized with an extra 1-byte length prefix after the 2-byte length `SvcParamValue` length prefix. These bugs, and others the fuzzer may yet find, could impact the correctness of the recursor, since it round-trips records through `hickory_proto::rr::record_data::RData`. This project is set up in OSS-Fuzz, but there's a [build issue](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=71005) preventing it from working currently. There are similar issues with other Rust projects right now, so it's likely an issue with incompatibilities between dependencies and the old nightly toolchain that OSS-Fuzz has pinned. (they're currently blocked on upgrading to a newer nightly toolchain because their coverage tooling doesn't yet support LLVM 18) This should be straightforward to fix, by downgrading dependencies before building the fuzzer, in order to get continuous fuzzer coverage going again.

kerem closed this issue

2026-03-16 01:07:55 +03:00

kerem commented

2026-03-16 01:08:02 +03:00

Author

Owner

@divergentdave commented on GitHub (Aug 13, 2024):

I opened google/oss-fuzz#12342 to fix the OSS-Fuzz build. This was just a rebrand-related issue.

@divergentdave commented on GitHub (Aug 13, 2024): I opened google/oss-fuzz#12342 to fix the OSS-Fuzz build. This was just a rebrand-related issue.

kerem commented

2026-03-16 01:08:07 +03:00

Author

Owner

@djc commented on GitHub (Aug 19, 2024):

So I guess this can be closed, right?

@djc commented on GitHub (Aug 19, 2024): So I guess this can be closed, right?

kerem commented

2026-03-16 01:08:12 +03:00

Author

Owner

@divergentdave commented on GitHub (Aug 19, 2024):

The other two issues I listed above aren't fixed yet, and there may be others, but OSS-Fuzz should rediscover these and file Monorail issues soon. We could keep this as a tracking issue, or leave it closed, either way.

@divergentdave commented on GitHub (Aug 19, 2024): The other two issues I listed above aren't fixed yet, and there may be others, but OSS-Fuzz should rediscover these and file Monorail issues soon. We could keep this as a tracking issue, or leave it closed, either way.

kerem referenced this issue

2026-03-16 02:27:48 +03:00

[PR #968] [CLOSED] Release/0.18 #1828