c-ares is an asynchronous resolver library. Prior to 1.34.7, aresdnsnameparse() enforces backward DNS compression pointers but does not bound the total pointer hops or assembled name length. A malicious DNS server can send a response containing a long descending pointer chain and many resource records whose NAME or RDATA fields refer to the chain, causing repeated decompression work that grows quadratically with message size. A single crafted response can stall the single-threaded c-ares event loop and deny DNS resolution, without causing memory corruption or information disclosure. This issue is fixed in version 1.34.7.

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

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.