Ce mail provient de l'extérieur, restons vigilants ==================================================================== CERT-Renater Note d'Information No. 2026/VULN726 _____________________________________________________________________ DATE : 07/07/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running c-ares versions prior to 1.34.7. ==================================================================== https://github.com/c-ares/c-ares/security/advisories/GHSA-6wfj-rwm7-3542 https://github.com/c-ares/c-ares/security/advisories/GHSA-pjmc-gx33-gc76 https://github.com/c-ares/c-ares/security/advisories/GHSA-jv8r-gqr9-68wj _____________________________________________________________________ Use-after-free / double-free in c-ares query-completion handling, remotely triggerable via ares_getaddrinfo() over TCP High bradh352 published GHSA-6wfj-rwm7-3542 Package c-ares Affected versions > 1.32.3 Patched versions 1.34.7 Description Impact 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. It is reachable in two ways: Application-triggered: a callback that re-enters c-ares, for example by calling ares_cancel(). The callback frees the query and it is freed again after the callback returns. Remotely, with no application cooperation: via ares_getaddrinfo() over TCP. A malicious or on-path DNS server that returns a FORMERR without an OPT record (forcing an EDNS-downgrade retry), then a second response with the same query id, then resets the connection, causes ares_getaddrinfo()'s internal completion handler to re-enter (issuing a follow-on lookup whose send fails on the reset connection and completes immediately) and access a host_query that has already been freed. An attacker can force a client onto TCP by setting the truncation (TC) bit in a UDP response. This was reproduced deterministically under AddressSanitizer (heap-use-after-free in the ares_getaddrinfo() completion handler) against v1.34.6 and the development branch, using only the public API and the standard system allocator. The same pattern was previously addressed at one call site under CVE-2025-31498; CVE-2026-33630 covers the remaining occurrences of the pattern. The consequence is memory corruption leading to a crash (denial of service); a use-after-free may have further impact depending on the allocator and build. Reliable code execution has not been demonstrated. Patches Fixed in c-ares 1.34.7. All deferred retries and completions are routed through a single iterative drain, and each query is fully detached from every lookup structure before its callback is invoked, so re-entrancy — whether from a caller's ares_cancel() or from c-ares' own internal follow-on lookups — can no longer free a query that is still in use. The recursive resend path that amplified the problem is also removed. Fix commits: main: 1fa3b86 v1.34 (backport, PR #1237): d823199 Workarounds Avoid calling ares_cancel() from within a query callback. This does not address the remotely-triggered path, which is driven entirely by DNS responses and has no reliable application-level workaround; upgrade to a fixed release, and prefer trusted resolvers reached over a trusted transport. Credit Reported independently by multiple researchers. Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2026-33630 Weaknesses Weakness CWE-415 Weakness CWE-416 Credits @Oblivionsage Oblivionsage Reporter _____________________________________________________________________ CPU-exhaustion denial of service via unbounded DNS name compression pointer chains High bradh352 published GHSA-pjmc-gx33-gc76 Software c-ares Affected versions <= 1.34.6 Patched versions 1.34.7 Description Summary c-ares's DNS name decompression (ares_dns_name_parse()) enforced that every compression pointer must jump strictly backward, which prevents infinite loops, but placed no limit on the total number of pointer hops or on the assembled name length. A single crafted response could therefore make name decompression perform work quadratic in the message size. Details Within a single ~64 KB TCP response an attacker can lay down a long descending chain of compression pointers (each pointing to the previous one) and then many resource records whose NAME/RDATA names each point at the end of that chain. Every such name is fully re-walked from the referenced position back to the start, so a message with a few thousand records referencing an ~8,000-deep chain drives tens of millions of pointer-follow operations. The reporter measured a single 65,524-byte response taking ~2.85 s to parse versus ~5.7 ms for a same-size benign response (~497x slowdown). Because c-ares runs on a single-threaded event loop, this stalls all resolution for the duration; responses arriving faster than they parse deny service entirely. Impact A malicious or on-path DNS server responding to a victim's query can stall the c-ares event loop with individual crafted responses, degrading or denying DNS resolution for the application. Availability only -- no memory corruption or disclosure. Because one crafted response is sufficient to stall the single-threaded event loop, availability impact is scored High. Proof of concept A crafted ~65 KB TCP response containing an ~8,176-pointer descending chain in a RAW_RR RDATA followed by ~3,510 NS records that reference the chain end for both NAME and NSDNAME (~57M total pointer follows). Full reproducer provided in the private report. Patch Name parsing now caps the number of compression indirections at 128 (ARES_MAX_INDIRS, matching long-standing BIND behavior) and additionally enforces the RFC 1035 section 3.1 255-octet limit on the assembled (presentation) name length during decompression, so a name reached through a pointer chain can no longer be expanded without bound. v1.34 branch: 5c8341b (PR #1210, backport of #1164) main branch: f1288bb (PR #1164) Workarounds None. Upgrade to a release containing the fix (1.34.7 or later). Credit Reported by Haruto Kimura (@HarutoKimura) of Stella. Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID No known CVE Weaknesses Weakness CWE-407 _____________________________________________________________________ Memory-amplification denial of service via unvalidated DNS header record counts Moderate bradh352 published GHSA-jv8r-gqr9-68wj Software c-ares Affected versions <= 1.34.6 Patched versions 1.34.7 Description Summary When parsing a DNS response, c-ares pre-allocated per-section resource-record arrays sized directly from the attacker-controlled ANCOUNT, NSCOUNT, and ARCOUNT fields of the 12-byte DNS header, without first checking those counts against the number of bytes actually present in the message. A tiny response claiming the maximum record counts forced a large, disproportionate heap allocation. Details ares_dns_parse() is invoked from process_answer() before transaction-ID validation or question matching, so any received packet on a query's socket reaches the parser. The header counts (each up to 65535) drove ares_dns_record_rr_prealloc() -> ares_array_set_size(), which rounds the capacity up to the next power of two and allocates capacity * sizeof(ares_dns_rr_t). With ANCOUNT = NSCOUNT = ARCOUNT = 65535, this allocated on the order of ~15 MB of heap for a 12-byte input (roughly a 1,000,000:1 amplification). The allocation is released when parsing subsequently fails, but a sustained stream of such responses produces allocator pressure that can degrade or deny service. Impact A malicious or on-path DNS server (or an off-path spoofer able to land UDP responses on the query 4-tuple) can cause repeated large allocate/free cycles in any application using c-ares to resolve names. Availability only -- no memory corruption, information disclosure, or authentication bypass. Because the memory is transient (freed on parse failure) and impact materializes only under a sustained flood, availability impact is scored Low. Proof of concept A 12-byte DNS response consisting of only a header with QDCOUNT=0 and ANCOUNT=NSCOUNT=ARCOUNT=0xFFFF, parsed in a loop via ares_dns_parse(), produces multi-megabyte allocations per call (the reporter measured ~5,287 page faults per parse of the 12-byte packet). Full reproducer provided in the private report. Patch The parser now rejects a response whose combined record count cannot possibly fit in the remaining message bytes (total_rr_count > remaining_len / minimum_rr_wire_size, minimum RR = 11 bytes) before any pre-allocation occurs. v1.34 branch: e47c203 (PR #1134) main branch: eaded4c (PR #1134) Workarounds None. Upgrade to a release containing the fix (1.34.7 or later). Credit Reported by Haruto Kimura (@HarutoKimura) of Stella. Severity Moderate 5.3/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability Low CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L CVE ID No known CVE Weaknesses Weakness CWE-400 ======================================================== + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + ========================================================