c-ares: CPU-exhaustion denial of service via unbounded DNS name compression pointer chains
c-ares is an asynchronous resolver library. Prior to 1.34.7, ares_dns_name_parse() enforces backward DNS compression pointers but does not bound the total pointer hops or assembled name length. A malicious DNS server can send a response containing a long descending pointer chain and many resource records whose NAME or RDATA fields refer to the chain, causing repeated decompression work that grows quadratically with message size. A single crafted response can stall the single-threaded c-ares event loop and deny DNS resolution, without causing memory corruption or information disclosure. This issue is fixed in version 1.34.7.
c-ares: Memory-amplification denial of service via unvalidated DNS header record counts
c-ares is an asynchronous resolver library. Prior to 1.34.7, ares_dns_parse() trusts the attacker-controlled ANCOUNT, NSCOUNT, and ARCOUNT fields before confirming that the DNS response contains enough bytes for the claimed records. Because process_answer() invokes parsing before transaction ID and question validation, a malicious DNS response can cause ares_dns_record_rr_prealloc() and ares_array_set_size() to reserve disproportionate heap memory for a tiny message. Repeated responses create large allocation and release cycles that can degrade or deny name resolution, without causing memory corruption or information disclosure. This issue is
c-ares : Use-after-free / double-free in c-ares query-completion handling, remotely triggerable via ares_getaddrinfo() over TCP
c-ares is an asynchronous resolver library. From ver 1.32.3 until 1.34.7, a use-after-free / double-free in c-ares' query-completion handling. The same flaw — a query's callback being invoked while the query is still linked in the channel's internal lookup structures — is present at multiple points in the resend/finish path (timeout handling, response handling, and query dispatch). If the query, or for ares_getaddrinfo() the owning host_query, is freed as a side effect of that callback, it is then accessed and/or freed a second time. This vulnerability is fixed in ver 1.34.7.