Update dependency pycares to v4.9.0 [SECURITY] #62
+1
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
==4.4.0
->==4.9.0
GitHub Vulnerability Alerts
GHSA-5qpg-rh4j-qp35
Summary
pycares 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.
Details
Root Cause
The vulnerability stems from improper handling of callback references when the Channel object is destroyed:
ffi.new_handle()
This issue was much more likely to occur when using
event_thread=True
but could happen without it under the right circumstances.Technical Details
The core issue is a race condition between Python's garbage collector and c-ares's callback execution:
__del__
is called from within a c-ares callback context, we cannot immediately callares_destroy()
because c-ares is still executing code after the callback returnsImpact
Applications using
pycares
can be crashed remotely by triggering DNS queries that result inChannel
objects being garbage collected before query completion. This is particularly problematic in scenarios where:The error manifests as:
Fix
The vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism
Mitigation
For Application Developers
The fix is completely transparent - no API changes or code modifications are required.
Credit
This vulnerability was reported by @vEpiphyte through the aio-libs security program.
Release Notes
saghul/pycares (pycares)
v4.9.0
Compare Source
What's Changed
New Contributors
Full Changelog: saghul/pycares@v4.8.0...v4.9.0
v4.8.0
Compare Source
What's Changed
Full Changelog: saghul/pycares@v4.7.0...v4.8.0
v4.7.0
: 4.7.0What's Changed
Full Changelog: saghul/pycares@v4.6.1...v4.7.0
v4.6.1
: 4.6.1What's Changed
Full Changelog: saghul/pycares@v4.6.0...v4.6.1
v4.6.0
: 4.6.0Compare Source
What's Changed
is_all_ascii
for built-instr.isascii
by @bdraco in https://github.com/saghul/pycares/pull/209New Contributors
Full Changelog: saghul/pycares@v4.5.0...v4.6.0
v4.5.0
: 4.5.0Compare Source
What's Changed
New Contributors
Full Changelog: saghul/pycares@v4.4.0...v4.5.0
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.