CVE-2025-59529: 
Avahi vulnerability analysis and mitigation

CVE-2025-59529 is a local denial-of-service vulnerability in the Avahi mDNS/DNS-SD daemon's simple protocol server, caused by the failure to enforce a documented client connection limit. Although CLIENTS_MAX is defined in the codebase, server_work() unconditionally calls accept() and client_new() always appends new clients without checking the limit, allowing unlimited connections. All Avahi versions up to and including 0.9-rc2 are affected. The vulnerability was disclosed on December 18, 2025, with a CVSS v3.1 base score of 5.5 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is CWE-400 (Uncontrolled Resource Consumption): the server_work() function in avahi-daemon/simple-protocol.c unconditionally accepts incoming connections on the UNIX socket /run/avahi-daemon/socket without ever checking n_clients against CLIENTS_MAX. Each accepted connection causes client_new() to allocate memory and a file descriptor, incrementing n_clients indefinitely. When the daemon's file descriptor limit is reached, it enters an error-logging loop — emitting an accept(): Too many open files message for every subsequent connection attempt — which itself generates additional system load. Exploitation requires only low-privilege local access (no special permissions beyond the ability to connect to the UNIX socket) (GitHub Advisory, oss-security).

Unprivileged local users can exhaust avahi-daemon's memory and file descriptors, causing a system-wide denial of service for mDNS/DNS-SD functionality. Once file descriptors are exhausted, the daemon cannot accept legitimate requests, breaking *.local. name resolution and link-local address lookups for all applications relying on the nss-mdns plugin (e.g., glibc-based name resolution). The continuous error logging also increases overall system load. DBus-based resolution tools (avahi-resolve, avahi-resolve-address, avahi-resolve-host-name) are not directly affected, but the broader mDNS/DNS-SD service discovery infrastructure is disrupted (GitHub Advisory, ZeroPath Blog).

1. Reconnaissance: Confirm the target system is running avahi-daemon (version ≤ 0.9-rc2) and that the UNIX socket /run/avahi-daemon/socket is accessible to the current (unprivileged) user.
2. Flood the socket: Execute the following shell script to open thousands of idle connections to the simple protocol socket:

for i in $(seq 1 4000); do
  socat - UNIX-CONNECT:/run/avahi-daemon/socket >/dev/null 2>&1 &
done
wait

3. Exhaust file descriptors: As connections accumulate, avahi-daemon's file descriptor count grows until it hits the system limit, at which point it can no longer accept new connections.
4. Trigger error logging loop: Once the FD limit is reached, the daemon enters a continuous loop logging accept(): Too many open files for every subsequent connection attempt, further increasing system load.
5. Observe impact: mDNS/DNS-SD name resolution for *.local. domains and link-local addresses fails system-wide; applications relying on nss-mdns cannot resolve local names (GitHub Advisory, oss-security).

• Logs: Repeated accept(): Too many open files messages in avahi-daemon's log (e.g., /var/log/syslog, journalctl -u avahi-daemon); high-frequency error log entries from avahi-daemon indicating FD exhaustion.
• Process/Resource: Abnormally high file descriptor count for the avahi-daemon process (check via ls /proc/$(pidof avahi-daemon)/fd | wc -l or lsof -p $(pidof avahi-daemon) | wc -l); elevated memory consumption by avahi-daemon.
• Network/Socket: Large number of connections to /run/avahi-daemon/socket from a single unprivileged user (check via ss -x | grep avahi or lsof /run/avahi-daemon/socket).
• System: Failures in *.local. DNS resolution for applications using nss-mdns; increased system load average correlating with avahi-daemon log flooding (GitHub Advisory).

No officially patched release of Avahi exists as of the vulnerability disclosure date; a candidate fix is available in GitHub Pull Request #808, which enforces a client limit derived from rlimit-nofile (max_clients = min(4096, rlimit_nofile × 3/4)) with per-UID sub-limits. Until a patched release is available, the following workarounds are recommended:

• Manually restrict permissions on /run/avahi-daemon/socket after daemon startup to limit which users can connect (avahi-daemon provides no built-in configuration for this).
• Apply mandatory access controls via SELinux or AppArmor to prevent untrusted users from accessing the socket.
• Use only DBus-based resolution tools (avahi-resolve, avahi-resolve-address, avahi-resolve-host-name) where possible, as they are not affected by this vulnerability.
• Monitor avahi-daemon file descriptor and memory usage to detect exploitation attempts (GitHub Advisory, oss-security).

The vulnerability was responsibly disclosed by Joshua Rogers via the ZeroPath tool, with a detailed write-up published on the ZeroPath blog. The oss-security mailing list post by Alan Coopersmith (Oracle Solaris Engineering) helped amplify awareness in the open-source security community. A Reddit thread in r/cybersecurity discussed the logic flaw and its implications. The Yocto Project security mailing list has tracked the CVE across multiple weekly digest messages, indicating ongoing concern in the embedded Linux ecosystem. The fix PR (#808) has seen active but slow-moving review, with collaborators noting cross-platform portability challenges (particularly FreeBSD compatibility) as a blocker for merging (ZeroPath Blog, oss-security, GitHub PR #808).