{"id":"CVE-2025-48945","aliases":["GHSA-5qpg-rh4j-qp35"],"url":"https://o3.security/vulnerability/CVE-2025-48945","summary":"pycares has a Use-After-Free Vulnerability","details":"## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python's garbage collector and c-ares's callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn't properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares >= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.","published":"2025-06-20T19:14:27.403Z","modified":"2026-10-28T02:30:35.849843307Z","cvss":null,"epss":null,"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"PyPI","name":"pycares","fixedVersion":"4.9.0"}],"fix":{"url":"https://github.com/aio-libs/aiodns/commit/f259a6e3650555157af53ac2b39f2ff545321d55","label":"aio-libs/aiodns@f259a6e"},"references":[{"type":"WEB","url":"https://github.com/aio-libs/aiodns/releases/tag/v3.5.0"},{"type":"WEB","url":"https://github.com/saghul/pycares/releases/tag/v4.9.0"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/48xxx/CVE-2025-48945.json"},{"type":"ADVISORY","url":"https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-48945"},{"type":"FIX","url":"https://github.com/aio-libs/aiodns/commit/f259a6e3650555157af53ac2b39f2ff545321d55"},{"type":"FIX","url":"https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"},{"type":"PACKAGE","url":"https://github.com/saghul/pycares"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-10-28T02:30:35.849843307Z"}}