VYPR
← All advisories
High severityOSV Advisory· Published Sep 4, 2024· Updated Nov 20, 2025

Containers/aardvark-dns: tcp query handling flaw in aardvark-dns leading to denial of service

CVE-2024-8418

Description

A flaw was found in Aardvark-dns, which is vulnerable to a Denial of Service attack due to the serial processing of TCP DNS queries. An attacker can exploit this flaw by keeping a TCP connection open indefinitely, causing the server to become unresponsive and resulting in other DNS queries timing out. This issue prevents legitimate users from accessing DNS services, thereby disrupting normal operations and causing service downtime.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Aardvark-dns processes TCP DNS queries serially, allowing a single open connection to cause a denial of service by blocking all subsequent queries.

Vulnerability

Description

A flaw in Aardvark-dns arises from its serial processing of TCP DNS queries. When the server receives a TCP query, it processes that connection to completion before accepting any new ones. An attacker can exploit this by opening a TCP connection and leaving it open indefinitely, preventing the server from handling any further DNS requests. This results in all other DNS queries timing out, effectively denying service to legitimate users [1][2].

Exploitation

An attacker does not require authentication; they only need network access to the Aardvark-dns service, which typically listens on port 53. By simply establishing a TCP connection to the DNS server and never sending the expected query (or never closing the connection), the server remains blocked in processing that single connection. The issue is compounded because the server does not enforce a timeout on idle TCP connections, allowing the attack to persist as long as the attacker keeps the connection active [3][4].

Impact

Successful exploitation leads to a complete denial of service for DNS resolution handled by Aardvark-dns. Containers and hosts relying on this DNS server will be unable to resolve domain names, breaking network connectivity for applications, container-to-container communication, and external access. In environments such as Podman and Netavark, which depend on Aardvark-dns for DNS in bridge networks, this can cause prolonged outages and disrupt normal operations [1][3][4].

Mitigation

Red Hat has released security updates for Aardvark-dns that address this vulnerability by implementing proper timeout handling for TCP connections and moving to concurrent processing of DNS queries. Users are advised to update to the latest patched version of Aardvark-dns as soon as possible to prevent exploitation [1][2]. Additionally, network administrators should monitor DNS traffic for unusual persistence of TCP connections, which may indicate an ongoing attack.

References
  1. https://access.redhat.com/errata/RHSA-2025:7094
  2. cve-details
  3. NVD - CVE-2024-8418
  4. DNS Stops working after some time in bridge network

AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
aardvark-dnscrates.io
>= 1.12.0, < 1.12.21.12.2

Affected products

5

Patches

1
aa109bbd6743

tcp: add timeout to connection

https://github.com/containers/aardvark-dnsPaul HolzingerAug 30, 2024via ghsa
commit
1 file changed · +16 −2
  • src/dns/coredns.rs+16 −2 modified
    @@ -23,6 +23,7 @@ use std::io::Error;
 use std::net::{IpAddr, SocketAddr};
 use std::sync::Arc;
 use std::sync::Mutex;
+use std::time::Duration;
 use tokio::net::TcpListener;
 use tokio::net::UdpSocket;
 
@@ -108,8 +109,21 @@ impl CoreDns {
         let (mut hickory_stream, sender_original) =
             TcpStream::from_stream(AsyncIoTokioAsStd(stream), peer);
 
-        while let Some(message) = hickory_stream.next().await {
-            self.process_message(message, &sender_original, Protocol::Tcp)
+        // It is possible for a client to keep the tcp socket open forever and never send any data,
+        // we do not want this so add a 3s timeout then we close the socket.
+        match tokio::time::timeout(Duration::from_secs(3), hickory_stream.next()).await {
+            Ok(message) => {
+                if let Some(msg) = message {
+                    self.process_message(msg, &sender_original, Protocol::Tcp);
+                    // The API is a bit strange, first time we call next we get the message,
+                    // but we must call again to send our reply back
+                    hickory_stream.next().await;
+                }
+            }
+            Err(_) => debug!(
+                "Tcp connection {} was cancelled after 3s as it took to long to receive message",
+                peer
+            ),
         }
     }

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.