Bug: `getaddrinfo_with_timeout` use-after-free on Linux (getaddrinfo_a path)

[ratman]

Summary

When CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO is defined on Linux/glibc, getaddrinfo_with_timeout() has a use-after-free bug that causes heap corruption and SIGSEGV. The function uses getaddrinfo_a(GAI_NOWAIT) with a stack-local struct gaicb, and when gai_suspend() times out, it calls gai_cancel() but returns immediately without waiting for the cancellation to complete. The async DNS worker thread continues to reference the destroyed stack frame.

Version

httplib 0.43.1

Root Cause

In httplib.h, getaddrinfo_with_timeout() (around line 5880):

#elif defined(_GNU_SOURCE) && defined(__GLIBC__) && \
    (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))
  struct gaicb request;                          // ← stack-local
  struct gaicb *requests[1] = {&request};
  // ...
  int start_result = getaddrinfo_a(GAI_NOWAIT, requests, 1, &sevp);
  // ...
  int wait_result = gai_suspend(..., &timeout);

  // ...
  } else if (wait_result == EAI_AGAIN) {
    gai_cancel(&request);   // ← may return EAI_NOTCANCELED
    return EAI_AGAIN;       // ← destroys 'request' while DNS thread still uses it
  }

gai_cancel() is non-blocking. Per the man page, it can return:

• EAI_CANCELED — successfully canceled
• EAI_NOTCANCELED — request still in progress, could not be canceled
• EAI_ALLDONE — already completed

When it returns EAI_NOTCANCELED, the async DNS thread spawned by getaddrinfo_a is still running and still references request.ar_name, request.ar_request, etc. The function returns, the stack frame is destroyed, and the DNS thread writes to freed memory.

This corrupts the heap. The symptom is typically SIGSEGV in an unrelated thread's malloc/free, often many seconds later when the corrupted heap metadata is traversed.

How to Trigger

DNS resolution must take longer than connection_timeout_sec. This happens when:

• The network path to the DNS server is disrupted (interface toggle, cable unplug)
• The DNS server is unreachable or slow
• System DNS timeout (typically 5-30s) exceeds the httplib connection timeout (typically 2-5s)

Evidence

With ASAN's LeakSanitizer, the orphaned DNS threads leak resolver memory:

Direct leak of 84 byte(s) in 3 object(s) allocated from:
    #0 malloc
    #1 __GI___res_context_send resolv/res_send.c:325
    #2 __GI___res_context_query resolv/res_query.c:218
    #3 __res_context_querydomain resolv/res_query.c:629
    #4 __GI___res_context_search resolv/res_query.c:385
    #5 __GI__nss_dns_gethostbyname4_r nss_dns/dns-host.c:418
    #6 get_nss_addresses nss/getaddrinfo.c:652
    #7 gaih_inet nss/getaddrinfo.c:1185
    #8 __GI_getaddrinfo nss/getaddrinfo.c:2390
    #9 handle_requests resolv/gai_misc.c:329    ← getaddrinfo_a worker thread
    #10 start_thread nptl/pthread_create.c:448

These are the same threads that access the destroyed struct gaicb on the caller's stack.

Suggested Fix

After calling gai_cancel(), wait for the async operation to actually complete before returning:

  } else if (wait_result == EAI_AGAIN) {
    gai_cancel(&request);
    // gai_cancel is non-blocking — the async thread may still be running.
    // We must wait until it finishes before destroying the stack-local request.
    while (gai_error(&request) == EAI_INPROGRESS) {
      struct timespec wait = {0, 1000000}; // 1ms
      nanosleep(&wait, nullptr);
    }
    if (request.ar_result) { freeaddrinfo(request.ar_result); }
    return EAI_AGAIN;
  } else {
    gai_cancel(&request);
    while (gai_error(&request) == EAI_INPROGRESS) {
      struct timespec wait = {0, 1000000};
      nanosleep(&wait, nullptr);
    }
    if (request.ar_result) { freeaddrinfo(request.ar_result); }
    return wait_result;
  }

Alternative: use gai_suspend again (with a short timeout) instead of busy-polling gai_error.

Environment

• Linux x86_64, glibc 2.40 (Debian trixie)
• httplib 0.38.0
• Compiled with -DCPPHTTPLIB_OPENSSL_SUPPORT -DCPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO
• g++ 14, -std=gnu++20

[yhirose]

@ratman thanks for the report. It's pretty difficult for me to reproduce this problem on my MacBook. Could you send me a pull request with the above suggestion and include a unit test in test/test.cc to to reproduce this problem? Thanks a lot!

[yhirose]

@ratman actually, the most helpful thing is to provide me to the smallest possible code to reproduce this problem, then I can review your suggestion. Thanks!

[ratman]

I will do it this afternoon, sorry for not providing it immediately. I did my research during the night from Friday to Saturday and my family is not tolerating weekend work (or not well...). I wanted to post the ticket before I loose momentum. I have a reproduction, but not clean enough and might not be portable.

Otherwise, how I encountered it:
I have a client that is regularly polling an API, but my network connection seems to have hiccups. The server API is running on happens to be the DNS server too. So while my polling thread is running, I turn the network on/off, and sooner or later, (but rather sooner), it breaks.

[ratman]

sudo iptables -I OUTPUT -p udp --dport 53 -j DROP

#ifndef CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO
#define CPPHTTPLIB_USE_NON_BLOCKING_GETADDRINFO
#endif

#include <httplib.h>

#include <atomic>
#include <chrono>
#include <cstdlib>
#include <iostream>
#include <string>
#include <thread>
#include <vector>



int main() {
    const std::string host = "api.mylabor";
    constexpr int port = 443;
    constexpr int timeout_sec = 2;
    constexpr int num_threads = 16;
    constexpr int duration_sec = 300;


    std::cerr << "httplib crash reproducer\n"
              << "  host:     " << host << ":" << port << "\n"
              << "  timeout:  " << timeout_sec << "s\n"
              << "  threads:  " << num_threads << "\n"
              << "  duration: " << duration_sec << "s\n"
              << "  httplib:  " << CPPHTTPLIB_VERSION << "\n\n"
              << "Make sure DNS is blocked (iptables -I OUTPUT -p udp --dport 53 -j DROP)\n"
              << "so that getaddrinfo hangs and the timeout path is exercised.\n\n";

    std::atomic<int> total_attempts{0};
    std::atomic<bool> stop{false};

    auto worker = [&](const int id) {
        while (!stop.load(std::memory_order_relaxed)) {
            httplib::SSLClient client(host, port);
            client.set_connection_timeout(timeout_sec, 0);
            client.set_read_timeout(timeout_sec, 0);
            client.set_write_timeout(timeout_sec, 0);
            client.enable_server_certificate_verification(false);

            const auto res = client.Get("/");

            if (const int n = total_attempts.fetch_add(1, std::memory_order_relaxed) + 1; n % 50 == 0) {
                std::cerr << "[" << n << "] thread " << id
                          << (res ? " connected" : " failed") << "\n";
            }
        }
    };

    std::vector<std::thread> threads;
    threads.reserve(num_threads);
    for (int i = 0; i < num_threads; ++i)
        threads.emplace_back(worker, i);

    std::this_thread::sleep_for(std::chrono::seconds(duration_sec));
    stop.store(true, std::memory_order_relaxed);

    for (auto &t : threads)
        t.join();

    std::cerr << "\nCompleted " << total_attempts.load() << " attempts without crash.\n";
    return 0;
}

sudo iptables -D OUTPUT -p udp --dport 53 -j DROP