c-ares / c-ares / 28796095331

90%

push

github

Merge commit from fork

* Fix double-free in process_timeouts() when ares_cancel() called from callback

Detach query from queries_by_qid and all_queries before invoking
callback to prevent ares_cancel() from finding and double-freeing it.

This applies the same requeue pattern used in read_answers() to
process_timeouts().

* Consolidate requeue handling: fix #1043 recursion and complete the double-free fix

The prior commit fixed the process_timeouts() double-free (GHSA-6wfj-rwm7-3542 /
CVE-2026-33630) by deferring callbacks and detaching the query before invoking
it.  However:

  1. The identical double-free is reachable through read_answers(): its deferred
     ENDQUERY flush invoked the callback without first detaching the query from
     queries_by_qid / all_queries, so a reentrant ares_cancel() from a *normal*
     response callback frees the query and read_answers() frees it again.  The
     advisory's premise that read_answers() was already safe holds only for
     cross-query cancellation, not self-cancellation.

  2. Issue #1043 (unbounded ares_requeue_query() -> ares_send_query() recursion
     leading to stack overflow) was still present: ares_send_query() and the
     read_answers()/process_timeouts() flushes re-dispatched retries by calling
     ares_send_query() directly rather than iteratively.

Both problems share one root cause: work that must be deferred was instead done
immediately.  This change funnels every flush site through a single helper,
ares_flush_requeue(), which:

  - re-dispatches retries by appending to the same list and looping (via the new
    internal ares_send_query_int()), so retryable failures iterate instead of
    recursing, and
  - fully detaches each query (ares_detach_query()) before invoking its callback,
    so a reentrant ares_cancel() can never find and double-free it.

ares_send_query() becomes a thin wrapper that drives ares_send_query_int() and
drains the list.  Because a deferred retry can terminally ... (continued)

79 of 92 new or added lines in 2 files covered. (85.87%)

24323 of 27033 relevant lines covered (89.98%)

24383.65 hits per line