CVE-2025-59529
Denial of Service in Avahi Daemon via Unlimited Client Connections
Publication date: 2025-12-18
Last updated on: 2025-12-18
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| avahi | avahi | 0.9-rc2 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in Avahi's simple protocol server allows unprivileged local users to open unlimited client connections because the server ignores the configured client limit. The server accepts new connections without checking the maximum allowed clients, leading to exhaustion of memory and file descriptors. This causes a denial of service (DoS) system-wide for mDNS/DNS-SD services, increased system load due to excessive logging errors, and disruption of name resolution for *.local names and link-local addresses. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the UNIX socket /run/avahi-daemon/socket by changing its permissions after the avahi-daemon has started, and applying additional access controls such as SELinux policies to prevent unprivileged users from opening unlimited connections. Since the socket cannot be disabled and no official patched version is available yet, these access restrictions help reduce exploitation risk. Using tools that rely on DBus for resolution (like avahi-resolve, avahi-resolve-address, and avahi-resolve-host-name) is safe as they are not affected. Monitoring and limiting local user access to the socket is recommended until an official patch is released. [2]
How can this vulnerability impact me? :
The impact of this vulnerability is a system-wide denial of service affecting mDNS and DNS-SD services. Unprivileged local users can exhaust the avahi-daemon's memory and file descriptors by opening unlimited connections, causing the daemon to become unresponsive or crash. This also leads to increased system load from continuous logging errors. As a result, applications relying on glibc calls with nss-mdns plugins will fail to resolve local network names and link-local addresses, potentially disrupting network service discovery and related functionalities. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the avahi-daemon's resource usage and logs for signs of exhaustion of memory and file descriptors, as well as repeated error messages such as "accept(): Too many open files". A proof-of-concept uses the socat tool to flood the UNIX simple-protocol socket (/run/avahi-daemon/socket) with thousands of idle connections, which can be used to test the vulnerability. For detection, you can check the number of open connections to the socket and monitor system logs for excessive error messages related to avahi-daemon. Example command to test connection flooding: `socat - UNIX-CONNECT:/run/avahi-daemon/socket` (repeated multiple times to simulate many clients). Monitoring commands could include checking open file descriptors for avahi-daemon with `lsof -p $(pidof avahi-daemon)` and reviewing system logs for repeated accept errors. [2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA. The vulnerability causes a denial of service affecting mDNS/DNS-SD services locally, but there is no mention of data breach, confidentiality, or integrity issues that would typically affect regulatory compliance.