GHSA-6w6g-hm98-mhgm: Rust/hickory-resolver vulnerability
When the hickory-resolver name server pool implementation receives an upstream response with the TC (truncated) header bit set, it re-queues the request to the same nameserver to retry with UDP transport disabled. However, the retry arm never inspects the transport that just answered and carries no iteration counter. An authoritative server that sets TC=1 on every available transport keeps the resolver spinning on one persistent TCP connection until the 5s per-request wall-clock deadline expires.
Reporter
Qifan Zhang, Palo Alto Networks
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/hickory-resolverto a version that resolves this vulnerability.Fixed in 0.26.2
Event History
Frequently Asked Questions
What would an attacker need to do to trigger the retry loop?
They would need an authoritative server to return responses with the TC bit set on every available transport. The resolver then continues retrying against that server rather than completing the request.
Will the resolver fail over to another nameserver during this condition?
No. The request is re-queued to the same nameserver, and the retry path does not track the transport that produced the truncated response.
How long can an affected request remain stuck?
The resolver can spin on one persistent TCP connection until the per-request wall-clock deadline of 5 seconds expires.