fix(deps): update rust crate hickory-proto to 0.26.0 [security] - #181
Closed
renovate[bot] wants to merge 1 commit into
Closed
fix(deps): update rust crate hickory-proto to 0.26.0 [security]#181renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
4 tasks
Contributor
Contributor
Author
Renovate Ignore NotificationBecause you closed this PR without merging, Renovate will ignore this update ( If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.25.2→0.26.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
hickory-proto vulnerable to CPU exhaustion during message encoding due to O(n²) name compression
GHSA-q2qq-hmj6-3wpp
More information
Details
During message encoding,
hickory-proto'sBinEncoderstores pointers to labels that are candidates for name compression in aVec<(usize, Vec<u8>)>. The name compression logic then searches for matches with a linear scan.A malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.
This is similar to CVE-2024-8508.
Reporter
Qifan Zhang, Palo Alto Networks
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
GHSA-3v94-mw7p-v465 / RUSTSEC-2026-0118 / RUSTSEC-2026-0120
More information
Details
The NSEC3 closest-encloser proof validation in
hickory-proto's (0.25.0-alpha.3 ... 0.25.2) andhickory-net's (0.26.0-alpha.1 .. 0.26.0)DnssecDnsHandlewalks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of the SOA owner, terminating only when the current candidate equals the SOA name. When the SOA in a response's authority section is not an ancestor of the QNAME, the loop stalls at the DNS root and never terminates, repeatedly callingName::base_name()and pushing newly allocatedNameand hashed-name entries into the candidateVec.The bug is reachable by any caller of
DnssecDnsHandle, including the resolver, recursor, and client, when built with thednssec-ringordnssec-aws-lc-rsfeature and configured to perform DNSSEC validation. It is triggered while validating a NoData or NXDomain response whose authority section contains an SOA record from a zone other than an ancestor of the QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice this can be reached through an insecure CNAME chain that crosses zone boundaries into a DNSSEC-signed zone returning NoData, but the minimum condition is just a mismatched SOA owner on a response requiring NSEC3 validation.A
debug_assert_ne!(name, Name::root())guards the loop body, so debug builds abort with a panic on the first iteration past the root. Release builds compile the assertion out and run the loop unbounded, allocating until the process exhausts available memory. A reachable upstream attacker who can return such a response can therefore crash a debug build or exhaust memory on a release build, for the affected configurations.The affected code was migrated from
hickory-prototohickory-netas part of the 0.26.0 release. Hickory DNS recommends that all affected users update tohickory-net0.26.1 for the fix.Reporter
David Cook, ISRG
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
GHSA-3v94-mw7p-v465 / RUSTSEC-2026-0118 / RUSTSEC-2026-0120
More information
Details
The NSEC3 closest-encloser proof validation in
hickory-proto'sDnssecDnsHandlewalks from the QNAME up to the SOA owner name, building alist of candidate encloser names. The iterator used assumes the
QNAME is a descendant of the SOA owner, terminating only when the current
candidate equals the SOA name. When the SOA in a response's authority section
is not an ancestor of the QNAME, the loop stalls at the DNS root and never
terminates, repeatedly calling
Name::base_name()and pushing newly allocatedNameand hashed-name entries into the candidateVec.The bug is reachable by any caller of
DnssecDnsHandle— including theresolver, recursor, and client — when built with the
dnssec-ringordnssec-aws-lc-rsfeature and configured to perform DNSSEC validation. It istriggered while validating a NoData or NXDomain response whose authority
section contains an SOA record from a zone other than an ancestor of the
QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
this can be reached through an insecure CNAME chain that crosses zone
boundaries into a DNSSEC-signed zone returning NoData, but the minimum
condition is just a mismatched SOA owner on a response requiring NSEC3
validation.
A
debug_assert_ne!(name, Name::root())guards the loop body, so debug buildsabort with a panic on the first iteration past the root. Release builds
compile the assertion out and run the loop unbounded, allocating until the
process exhausts available memory (OOM). A reachable upstream attacker who
can return such a response can therefore crash a debug-built validator or
exhaust memory on a release-built one.
The affected code was migrated from
hickory-prototohickory-netas part ofthe 0.26.0 release. The
hickory-proto0.26.x release no longer offersDnssecDnsHandleand so we recommend all affected users update tohickory-net0.26.1 when the implementation of that type is required.
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
hickory-proto vulnerable to CPU exhaustion during message encoding due to O(n²) name compression
GHSA-q2qq-hmj6-3wpp / RUSTSEC-2026-0119
More information
Details
During message encoding,
hickory-proto'sBinEncoderstores pointers to labels that are candidates for name compression in aVec<(usize, Vec<u8>)>. The name compression logic then searches for matches with a linear scan.A malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.
This is similar to CVE-2024-8508.
Reporter
Qifan Zhang, Palo Alto Networks
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
CPU exhaustion during message encoding due to O(n²) name compression
GHSA-q2qq-hmj6-3wpp / RUSTSEC-2026-0119
More information
Details
During message encoding,
hickory-proto'sBinEncoderstores pointers tolabels that are candidates for name compression in a
Vec<(usize, Vec<u8>)>.The name compression logic then searches for matches with a linear scan.
A malicious message with many records can both introduce many candidate labels,
and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
attacks.
This is similar to
CVE-2024-8508.
We recommend all affected users update to
hickory-proto0.26.1 for the fix.Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Release Notes
hickory-dns/hickory-dns (hickory-proto)
v0.26.1Compare Source
This point release for the 0.26 release series brings in several bug fixes, and no user-facing changes. Two security reports are addressed:
RUSTSEC-2026-0120 and RUSTSEC-2026-0119.
What's Changed
Full Changelog: hickory-dns/hickory-dns@v0.26.0...v0.26.1
v0.26.0: 0.26.0Compare Source
13 months after the release of 0.25.0, we finally have a bigger feature release of Hickory DNS, the suite of DNS libraries and authoritative/recursive name servers written in pure Rust. A lot of work has gone into this release, so we wanted to take a moment to release this before we continue work on deploying the Hickory DNS recursive resolver at Let's Encrypt (and did you see that Hickory is being used in some of Google's Pixel devices?). Because of the ongoing work, we expect that 0.27.0 might happen quite a bit sooner than in 13 months from now.
These release notes describe a number of high-level improvements as well as API changes that are likely to break a larger fraction of our downstream users. Feedback (both on these notes and the release itself) is always welcome in our issue tracker or via our Discord server.
Most of the following notes are broken up by specific components: the server binary and our library crates. However, for this release we've made several changes to the structure of our crates itself:
clientmodule (#3366). No future releases of the hickory-client crate are expected.recursorfeature which must be enabled explicitly. The recursor implementation was already tightly coupled to the resolver internals, so keeping it separate didn't really make sense.Additionally, substantial cross-crate changes have been made to improve our error handling:
hickory-dns (the server binary)
hickory-server (the library API)
Authoritytrait was renamed toZoneHandlerand simplified to better reflect its usage:hickory-resolver
We made many improvements to improve correctness and efficiency of both the recursive resolver and the "stub" resolver. In addition, we want to highlight the following changes:
hickory-net
We made substantial improvements to DNSSEC validation and our handling of potentially spoofing messages.
hickory-proto
Details
For more details, review the detailed release notes for our pre-releases:
and these final PRs merged after beta 4:
Thanks
Finally, we want to thank everyone who contributed to this release: @bryanlarsen, @billf, @hargut, @ibigbug, @xi0, @steffengy, @james7132, @Thomasdezeeuw, @Kriskras99, @mispp, @conradludgate, @nabijaczleweli, @musicinmybrain, @msrd0, @jmwample, @LAGonauta, @tisonkun, @provokateurin, @lemon-sh, @thomas-zahner, @jpds, @lpraneis, @zachsmith1, @jackboykin, @ZnqbuZ, @Jeidnx, @kn0sys, @matheus23, @benesch, @roblabla and of course our maintainers @cpu, @divergentdave, @marcus0x62 and @djc.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.