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 aresgetaddrinfo() the owning hostquery, 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.

c-ares has a Use After Free vulnerability when connection is cleaned up after error

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in readanswers() when processanswer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but readanswers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in readanswers() when processanswer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but readanswers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.

CVE-2025-31498

Impact

Patches

Versions 1.32.3 - 1.34.4 are affected. Patch in 1.34.5.

Workarounds

None

References https://github.com/c-ares/c-ares/releases/tag/v1.34.5

Credit

Reported by Erik Lax

CVE-2024-25629

Impact Patches

Fixed in c-ares 1.27.0

Workarounds

No workarounds exist.

Credit

Vojtěch Vobr

c-ares is a C library for asynchronous DNS requests. aresreadline() is used to parse local configuration files such as /etc/resolv.conf, /etc/nsswitch.conf, the HOSTALIASES file, and if using a c-ares version prior to 1.27.0, the /etc/hosts file. If any of these configuration files has an embedded NULL character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

Buffer overflow vulnerability in c-ares before 1161 thru 1170 via function aresparsesoareply in aresparsesoareply.c.

CVE-2023-32067. 0-byte UDP payload causes Denial of Service (https://github.com/c-ares/c-ares/security/advisories/GHSA-9g78-jv2r-p7vc)

c-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.

Description of issue(s): When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available.

CVE-2023-31147 Insufficient randomness in generation of DNS query IDs (https://github.com/c-ares/c-ares/security/advisories/GHSA-8r8p-23f3-64c2)

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

c-ares is an asynchronous resolver library. When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG. This issue was patched in version 1.19.1.

When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG.

CVE-2023-31124. Low. AutoTools does not set CARESRANDOMFILE during cross compilation (https://github.com/c-ares/c-ares/security/advisories/GHSA-54xr-f67r-4pc4)

A possible use-after-free and double-free in c-ares lib version 1.16.0 if aresdestroy() is called prior to aresgetaddrinfo() completing. This flaw possibly allows an attacker to crash the service that uses c-ares lib. The highest threat from this vulnerability is to this service availability.

The c-ares function aresparsenaptrreply(), which is used for parsing NAPTR responses, could be triggered to read memory outside of the given input buffer if the passed in DNS response packet was crafted in a particular way.

Heap-based buffer overflow in the arescreatequery function in c-ares 1.x before 1.12.0 allows remote attackers to cause a denial of service (out-of-bounds write) or possibly execute arbitrary code via a hostname with an escaped trailing dot.