CVE-2026-33630: c-ares : Use-after-free / double-free in c-ares query-completion handling, remotely triggerable via ares_getaddrinfo() over TCP

A use-after-free / double-free vulnerability was found 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 aresgetaddrinfo() the owning hostquery, 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:

1. Application-triggered: a callback that re-enters c-ares, for example by calling arescancel(). The callback frees the query and it is freed again after the callback returns.

2. Remotely, with no application cooperation: via aresgetaddrinfo() 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 aresgetaddrinfo()'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 hostquery 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 aresgetaddrinfo() 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.

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.

Fixed in c-ares 1.34.7.