CVE-2022-4904: c-ares Sortlist Overflow Fixed in 1.19.0

A stack‑overflow bug in the widely used asynchronous DNS library c‑ares — tracked as CVE‑2022‑4904 — allows unbounded input to overflow a local stack buffer during sortlist parsing, creating a denial‑of‑service condition and a limited confidentiality/integrity exposure; the defect was fixed upstream in the c‑ares 1.19.0 release and has been backported by major distributions, but the true operational risk depends heavily on how individual applications build and use the library.

Background / Overview​

c‑ares is a compact, cross‑platform C library that provides non‑blocking DNS lookups and helpers for name resolution; it is embedded into many networked projects, including libcurl, Node.js, Wireshark and a range of commercial products where asynchronous DNS is required. Because c‑ares is a low‑level library written in C and often compiled into larger executables, memory‑safety issues in its parsing logic can cascade into application crashes or worse depending on usage.
CVE‑2022‑4904 was reported in late 2022 and publicly recorded in early 2023: the root cause is missing bounds checks in the ares_set_sortlist code path (specifically the config_sortlist helper) that copies substrings into fixed‑size stack buffers without verifying length, enabling an arbitrary length stack overflow under crafted input. This was addressed by adding explicit length checks and returning an error for over‑long tokens. (github.com)
This article explains the vulnerability in practical terms, compares vendor assessments, reviews the upstream fix, outlines detection and mitigation steps for administrators and developers, and evaluates the realistic exploitability and supply‑chain implications for Windows‑centered and cross‑platform deployments.

---

How the flaw works (technical analysis)​

The vulnerable code path in plain language​

The public API in question is ares_set_sortlist(channel, sortstr). That function accepts a space‑separated string describing address/netmask pairs used to order DNS answers. The implementation delegates parsing to a helper — config_sortlist() — which tokenizes the input and copies substrings (IP address literals and optional prefixes) into local fixed‑size character arrays on the stack.
Because the original code performed string copies using memcpy without checking that the token length fit the target buffer, a maliciously crafted sortlist string containing overly long tokens can make memcpy write past the buffer bounds on the stack, causing stack corruption and a crash. The public proof‑of‑concept posted by the reporter demonstrates how a deliberately long token passed into ares_set_sortlist provokes the overflow. (github.com)

Upstream fix and rationale​

The upstream maintainers merged a small, targeted patch that adds explicit bounds checks before each memcpy and returns a parse error (ARES_EBADSTR) when a token exceeds safe limits (the patch enforces maximum lengths of 16 and 32 characters for the two different token buffers used). Unit tests were also extended to assert that malformed strings return ARES_EBADSTR. The precise commit is recorded in the project history and the change shipped in the c‑ares 1.19.0 release. (github.com)
By performing early validation and failing safely, the patch prevents the stack memory corruption without changing the public API or the normal behavior for valid administrator‑supplied sortlists.

---

Who is affected — scope and real‑world reach​

Library vs. application boundary​

• The library function ares_set_sortlist is usually called by program initialization code or by administrators configuring resolver behavior, not by routine network input handling. In many deployments the sortlist string comes from a static configuration file or build‑time parameter rather than from remote packets.
• Because of that typical usage pattern, most applications will not expose this code path to remote, unauthenticated attackers — the practical exploit surface is reduced when the API is only used with trusted, admin‑controlled strings.

Where this becomes higher risk​

However, real systems are messy:

• Applications that parse operator input, accept configuration via networked management interfaces, or embed c‑ares in environments that process untrusted strings could expose the vulnerable code path to remote actors.
• Static linking of c‑ares into widely distributed binaries (for example, custom IoT images, container images, or cross‑compiled runtimes) increases the blast radius because any product including a vulnerable c‑ares becomes an additional vector that must be updated.
• Vendors and downstream distributions that build or package c‑ares must update and ship patched binaries; major Linux distributions and several commercial product vendors did push updates after the upstream fix.

Official severity assessments (varying viewpoints)​

Different security authorities and vendors attach different severity metadata:

• The National Vulnerability Database and several distribution advisories document a High base score (CVSS 3.x 8.6) with Network attack vector, no privileges required, and high availability impact — i.e., the vulnerability is scored as capable of causing denial of service when the input is reachable remotely.
• Some vendor pages (and upstream project notes) emphasize that the vulnerable API is typically configured from trusted sources and that exploitation requires feeding the API a malicious string, leading to a lower practical risk rating in their specific context. The c‑ares changelog explicitly notes that ares_set_sortlist is "typically provided by an administrator and not an end user."

This divergence is important: severity labels matter, but context and deployment details change the operational risk.

---

Evidence and verification​

• The flaw was publicly tracked via a GitHub issue that included example code showing how ares_set_sortlist can be abused and the maintainers accepted and merged a patch that implements defensive length checks. The patch is present in the upstream Git history (commit 9903253) and the change was included in the c‑ares 1.19.0 release. (github.com)
• The NVD record reproduces the description of an arbitrary length stack overflow and lists the risk of denial of service or limited confidentiality/integrity impact.
• Major distributions, including Ubuntu and SUSE, list the CVE and published fixes in their packaging trees; Ubuntu’s advisory documents CVSS 3.1/3.x scoring at 8.6 and shows which package revisions include the fix.
• The c‑ares changelog and distribution patch queues (Yocto, SUSE, Red Hat, etc.) show backports and distribution packaging work to remediate the issue.

Where vendor guidance differs (for example, whether exploitation is a local or network vector), those differences are attributable to assumptions about how the API is used within particular products. Those assumptions must be validated in every environment before concluding that a system is not exploitable.

---

Exploitability: realistic scenarios​

Let’s separate theory from likely practice.

• Theoretical exploit: Given control of the string passed to ares_set_sortlist, an attacker can overflow a stack buffer, which may cause a crash (DoS) and in some circumstances permit control of instruction flow (remote code execution). The vulnerability was introduced by unchecked memcpy of variable‑length tokens. (github.com)
• Practical constraints:
• If an application calls ares_set_sortlist only with administrator‑controlled text (hardcoded, from resolv.conf or from secure configuration channels), then remote exploitation is unlikely.
• If a product accepts untrusted configuration over management APIs, HTTP endpoints, or in container images / build artifacts that include a crafted sortlist, that product could be remotely exploitable.
• The presence of stack canaries, compiler hardening (FORTIFY, -fstack-protector), or modern OS mitigations (ASLR, DEP) reduces the probability of reliable RCE; at minimum the bug reliably produces crashes and thus a denial of service. (github.com)

Vendor‑specific advisories (for example, IBM’s bulletin for App Connect Enterprise containers) described higher impact scenarios where c‑ares in a runtime or container is fed untrusted inputs or is cross‑compiled into widely exposed services; those bulletins typically gave a more severe (networkable) attack vector. This is why some product teams raised urgency even though the upstream project described the API as admin‑supplied.

---

Detection and hunting guidance​

If you are responsible for systems or software that might include vulnerable c‑ares code, take the following steps to find and prioritize affected assets.

• Identify c‑ares in your stack
• Search binaries and packages for c‑ares usage and versions:
• On Debian/Ubuntu: dpkg -l | grep c-ares or apt-cache policy c-ares
• On RHEL/CentOS/Fedora: rpm -qa | grep c-ares
• For statically linked binaries: strings <binary> | grep -i c-ares or run ldd <binary> to see the linked libraries where applicable.
• Check container images and firmware builds for c‑ares artifacts and the specific version string.
• Inspect vendor supply‑chain manifests and SBOMs for the presence of c‑ares and which version is included.
• Look for usage of the sortlist API
• Grep or search source trees for calls to ares_set_sortlist or for code that passes user‑supplied strings into resolver init routines.
• Audit management planes and web GUIs that accept configuration strings — any place a maintainer or operator can change resolver preferences could be a path for an attacker to inject a malicious sortlist.
• Runtime indicators
• Unexpected crashes or process restarts in components that embed c‑ares during startup or configuration changes.
• Application logs that show failures during resolver initialization or errors returned from ares_set_sortlist (the patched code returns ARES_EBADSTR for malformed inputs). After patching, successful defensive behavior may be logged as parse errors rather than crashes. (github.com)

---

Mitigation and remediation (what to do now)​

• Upgrade the c‑ares library
• The upstream patch was merged and the fix shipped in c‑ares 1.19.0. Upgrade any direct usages to 1.19.0 or later.
• For packaged systems, install the distribution security update that contains the patched c‑ares build (Ubuntu, Fedora, RHEL, SUSE, Debian have issued updates). Verify package versions against vendor advisories and release notes.
• For statically linked or embedded builds
• Rebuild affected binaries with the patched upstream code and redeploy. Static linking is common in embedded systems, vendor appliances and some container images — these must be rebuilt and republished to customers.
• Where rebuilding is not immediately possible, consider limiting access to management interfaces that could accept configuration strings that reach ares_set_sortlist.
• Harden compilation and runtime
• Use compiler hardening and link‑time protections (stack canaries, PIE/ASLR, DEP) to reduce the chance of successful exploitation.
• Run fuzzing against exposed inputs and configuration fields in your product to catch similar issues pre‑release.
• Enforce least privilege and network segmentation
• If a runtime exposes management endpoints, restrict their access via firewalls and authentication; treat configuration interfaces as high‑risk entry points.
• Segment administrative networks to reduce the likelihood that untrusted actors can feed malicious parameters into resolvers.
• Monitor for updates and backports
• Subscribe to distribution security feeds and the c‑ares project announcements for patch notices and followup advisories. Ensure your patch management pipeline picks up library updates and rolls them into builds and images.

---

Recommendations for developers and product teams​

• Do not assume an API that should only receive trusted input cannot become reachable by an attacker. Configuration channels shift over time; a management UI added later, or a new configuration import feature, can make a previously safe API reachable.
• When writing C code that parses strings, always validate token lengths and prefer bounded copy APIs. Prefer unit tests that exercise boundary conditions; the upstream c‑ares patch included additional unit tests that assert failure semantics for overly long tokens. (github.com)
• Maintain an SBOM and track third‑party component versions so that when a new CVE is published you can quickly identify affected products and push fixes to customers.
• For open‑source projects: prefer exposing safe wrappers that only accept validated input, and document clearly which strings are expected to be operator‑supplied versus user‑supplied.

---

Supply‑chain and operational risk analysis​

A single memory‑safety bug in a small library can have outsized operational impact because:

• Libraries like c‑ares are frequently embedded and statically linked into larger programs, which means tens or hundreds of downstream products inherit the vulnerability until they explicitly rebuild.
• Container images and firmware images used across fleets are often built once and deployed widely; older images can linger and remain vulnerable.
• The distinction between local vs. network exploitability is often determined by architectural choices made by product teams — choices that can change over a product’s lifecycle.

CVE‑2022‑4904 demonstrates both the strengths and weaknesses of the modern open‑source ecosystem:

• Strengths: The bug was reported, triaged, patched quickly, and the upstream project released a fix; distributions backported or packaged the patched release; security advisories and changelogs capture the resolution. This is the responsible‑disclosure cycle working as intended. (github.com)
• Weaknesses: The real world still contains many binary artifacts, containers, and embedded images that must be rebuilt and redeployed — a non‑trivial operational task. Vendors that ship prebuilt appliances or containers face customer support burdens to ensure customers update or receive patched images.

---

Attack surface reduction checklist (practical)​

• Inventory: Build or obtain an SBOM and locate c‑ares usage and version numbers across servers, desktops, containers and firmware.
• Patch: Prioritize updates for internet‑facing services, product builds that accept remote configuration, and any statically linked binaries.
• Block: Restrict access to admin interfaces that can change resolver parameters or upload configuration files.
• Audit: Search sources for calls to ares_set_sortlist and determine whether any user‑supplied input could reach that call.
• Test: After applying the fix, run integration tests that exercise resolver initialization and configurook for ARES_EBADSTR behavior on malformed inputs as a sign the library is now guarding correctly. (github.com)

---

Notable strengths and remaining risks​

Strengths:

• The fix itself is small, well scoped, and does not break legitimate behavior — it adds input validation and unit tests.
• Upstream resolved the issue promptly and released a formal version (1.19.0) that includes the patch.
• Major distributions and some vendors pushed updates, reducing the window of exposure for many users. (github.com)

Risks and caveats:

• Some operational environments may still contain unpatched, statically linked binaries or images where c‑ares is embedded and not updated automatically.
• Vendor advisories differ in how they classify the attack vector (network vs. local) because exploitability depends on product‑specific integration. Do not assume 'not exploitable' without auditing the exact code paths used in your product.
• While modern mitigations make reliable RCE less probable, crashes and denial‑of‑service remain straightforward outcomes for the bug if the offending input is reachable.

Historic context: c‑ares has seen memory‑safety issues in the past (for example CVE‑2020‑22217 in DNS parsing), illustrating that DNS parser code remains a fruitful area for hardening and fuzzing. The project’s own changelogs and external advisories document that ongoing attention to parsing routines pays dividends.

---

Final verdict and guidance​

CVE‑2022‑4904 is a concrete example of a small parsing bug that can have outsized operational consequences when third‑party libraries are embedded in a wide variety of products. The good news is that:

• The issue is fixed upstream (c‑ares 1.19.0) and has been packaged by major Linux distributors.
• The upstream fix is narrow and correct: input length checks and failure codes rather than silent memory corruption.

That said, your next steps must be practical and evidence‑driven:

• Inventory everywhere c‑ares is present in your environment (including static binaries and container images).
• Prioritize patching and rebuilds for internet‑exposed services and any software that exposes configuration channels to non‑administrative users.
• If you build products that distribute binaries to customers, publish updated binaries and clear migration guidance.
• Use this incident as a prompt to strengthen secure coding practices (bounded copies, fuzzing, unit tests) and to tighten your dependency management and SBOM workflows.

CVE‑2022‑4904 is a reminder: even admin‑oriented APIs can become attacker reachable over a product’s lifecycle — and fixing them cleanly (as the c‑ares maintainers did) is only part of the battle. The remainder is operational follow‑through: finding every instance in the wild, rebuilding affected artifacts, and clamping down on the paths that let untrusted strings reach code that manipulates memory directly. (github.com)

---

In closing: treat this CVE as an important but manageable memory‑safety issue. Apply the c‑ares 1.19.0+ update where possible, rebuild any statically linked deliverables, and audit configuration and management surfaces to ensure that attacker‑controlled input cannot be funneled into resolver initialization routines that were written with unsafe assumptions.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center