CVE-2026-35406: Denial of Service via Uncontrolled Resource Consumption in Aardvark-dns

Aardvark-dns operates as an authoritative DNS server for containerized environments, frequently deployed alongside tools like Podman to handle internal A/AAAA record resolution. The vulnerability, classified as Uncontrolled Resource Consumption (CWE-400), affects versions 1.16.0 through 1.17.0.

An attacker can trigger this flaw by sending a structurally incomplete TCP DNS query and subsequently terminating the connection. This specific sequence of network events initiates an unhandled error state within the asynchronous event loop responsible for processing TCP streams.

The resulting impact is a complete Denial of Service (DoS) for the DNS component. The unhandled error state causes the server to continuously poll the disconnected stream without blocking, driving CPU utilization to 100% on the affected core. This prevents the server from answering legitimate DNS queries originating from the container network.

The vulnerability originates in the TCP DNS stream polling logic located within src/dns/coredns.rs. The server implementation leverages the hickory-proto library to handle asynchronous stream iteration, retrieving incoming DNS messages over established TCP connections.

When a malformed packet arrives—specifically one announcing a TCP payload length but failing to deliver the corresponding payload before the connection resets—the underlying stream iterator returns an Err result. The application logic captures this error, writes the output to the debug log, but fails to alter the control flow of the connection loop.

The critical failure occurs because the asynchronous event loop immediately attempts to poll the same desynchronized stream again. Since the socket state remains persistently broken, every subsequent poll instantly returns another Err result.

This continuous polling executes without any artificial delay, blocking operations, or state validation. The tight execution loop rapidly exhausts available CPU cycles, locking the execution thread in a classic busy-wait scenario that degrades system availability.

The vulnerable implementation attempts to process the message stream without evaluating the structural integrity of the connection following an error. The stream's iterator yields an error, but the surrounding processing loop continues execution without dropping the broken connection.

The patch implemented in commit 3b49ea7b38bdea134b7f03256f2e13f44ce73bb1 introduces explicit match arms for the stream output. When Err(e) is encountered during message parsing, the execution path now includes a decisive break statement.

// Patched logic
match message {
    Some(msg_result) => match msg_result {
        Ok(msg) => {
            Self::process_message(&data, msg, ...).await
        }
        Err(e) => {
            debug!("Error parsing dns message {e:?}");
            // CRITICAL FIX: Break the loop on error
            break; 
        }
    },
    None => break,
}

This modification ensures that any parsing error immediately terminates the specific TCP connection loop. The server drops the problematic socket context and returns to polling healthy connections, effectively eliminating the infinite loop condition.

Exploitation requires the attacker to possess network routing capability to the target aardvark-dns service port (TCP 53). Authentication is not required, as the vulnerability triggers during the initial parsing of the TCP DNS protocol framing layer.

The attacker establishes a standard TCP connection to the target server and transmits a carefully crafted binary payload. The payload consists solely of the two-byte TCP DNS length prefix (e.g., 0x003c indicating a 60-byte message) without appending any subsequent DNS message data.

Immediately after transmitting the length prefix, the attacker sends a TCP RST (reset) or FIN to abruptly terminate the connection. Standard network utilities like socat can execute this precise sequence by writing raw bytes to standard input and closing the socket.

# Proof of Concept command
echo -e '\x00\x3c' | socat - TCP4:$gw:53

Upon receipt of the truncated transmission and subsequent reset, the aardvark-dns process immediately spikes to 100% CPU utilization. The service ceases to respond to subsequent valid DNS queries.

The primary impact is a severe degradation of network availability for containerized applications relying on aardvark-dns for name resolution. Applications attempting to resolve internal infrastructure or external web services experience DNS timeouts and subsequent connection failures.

The vulnerability is classified under CVSS v3.1 as 6.2 (Medium), with a vector of CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The Local (AV:L) vector reflects the requirement for the attacker to originate from within the adjacent container network or possess explicit routing to the DNS gateway interface.

Confidentiality and Integrity remain entirely uncompromised. The infinite loop occurs within the connection handling thread and does not expose memory contents, allow execution of arbitrary instructions, or permit the manipulation of internal DNS cache records.

Sustained exploitation can induce secondary impacts on the host system. Exhaustion of CPU resources on the assigned execution core degrades the performance of co-located containers or host processes depending on resource limitation configurations.

The primary remediation is to upgrade aardvark-dns to version 1.17.1. This release incorporates the upstream fix that correctly terminates the parsing loop upon encountering socket or protocol errors.

Administrators utilizing container management environments should update their associated dependency packages through the system package manager. For example, executing dnf update aardvark-dns on RPM-based distributions installs the patched binary. Administrators must ensure that all running container networks are restarted to load the patched binary into memory.

In environments where immediate patching is not feasible, administrators can deploy network-level rate limiting or connection state tracking on TCP port 53. Restricting the number of unestablished or rapidly resetting TCP connections mitigates automated exploitation attempts from compromised containers.

Security teams should implement process-level monitoring for aardvark-dns. Alerting logic should trigger if sustained CPU utilization reaches 100% concurrently with a high volume of Error parsing dns message debug entries in the service logs.