zeroconf has unbounded DNS record cache that allows LAN-local memory exhaustion via multicast flood

Impact

DNSCache._async_add inserted every response record into cache, _expirations, _expire_heap, and service_cache with no cap on entry count. The only pre-existing protection was a PTR TTL floor (_DNS_PTR_MIN_TTL = 1125 s, RFC 6762 §10), which actually *prolonged* attacker-injected records, and a periodic async_expire on _CACHE_CLEANUP_INTERVAL = 10 s that could not keep up with a flood.

Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can multicast valid mDNS responses with unique names (RFC 6762 §11 allows up to 253 bytes each) and watch them accumulate. On memory-constrained deployments (Home Assistant on Raspberry-Pi-class hardware is the canonical victim) sustained traffic OOM-kills the process; under lighter load, every cache lookup and every periodic expiry pass grows linearly slower, starving asyncio and breaking unrelated zeroconf consumers (discovery, registration, ServiceBrowser callbacks). A second variant — re-multicasting cached records with shifting TTLs — grows _expire_heap unbounded between cleanup runs without touching cache or _total_records.

Patches

Fixed in zeroconf 0.149.6 (PR #1718). Upgrade to >= 0.149.6.

Workarounds

There is no in-process workaround; upgrading is the fix. Otherwise, restrict mDNS (UDP/5353) to trusted Layer-2 segments via AP client isolation, guest-network separation, or host firewall rules.

Resources

• PR #1718, fix
• Issue #1715, public tracking issue
• RFC 6762 §10, RFC 6762 §11, CWE-400