Repository navigation
CPython 3.13: consolidated memory-safety and concurrency bugs #157196
Copy link
Copy link
Closed as not planned
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
Hello,
This issue consolidates 25 reproducible CPython 3.13 bugs involving memory safety and concurrency.
The bugs resulted from Python security research using static analysis. Each entry has a concrete PoC in the linked version-specific Gist. Although the collection is large, these bugs warrant inspection, especially the cases producing interpreter crashes, sanitizer failures, memory corruption, or similarly concrete failures.
This issue is associated with #157197 and #157198
Bugs
asyncioFuture callback registry race — Concurrent callback registration or removal can retire an unlocked callback-list item beforeremove_done_callback()promotes it, producing an ASan crash.- Unlocked
atexitcallback array — Concurrent registry operations can use stale callback records and crash, while re-entrant comparison can delete an unrelated replacement callback. BaseException.__setstate__()shared-dictionary race — Concurrent value replacement can reclaim a dictionary entry betweenPyDict_Next()and reference promotion.- Bytearray methods using unlocked shared storage — Concurrent storage replacement causes out-of-bounds reads and mixed-generation results across several bytearray operations.
bytes()conversion of a shared list — The exact-list conversion path can promote an item reclaimed by concurrent clear or resize, producing an ASan crash.- Shared CSV Reader state race — Concurrent
next()calls can reallocate and corrupt the Reader's unlocked parser buffer and state. - Shared CSV Writer record-buffer race — Concurrent
writerow()calls can overwrite one another and emit a row containing mixed input generations. FrameLocalsProxy.__getitem__()extra-local race — Concurrent proxy assignment or deletion can reclaim a borrowed extra-local value before promotion.- Writable live-frame fast-local race — Proxy replacement can free a fast-local value while the evaluator or
PyFrame_GetVar()is acquiring it, causing impossible object state and allocator corruption. - Function closure replacement during frame initialization — Concurrent closure replacement can release the tuple and cell while an unstarted frame initializes its free variables.
- Unsynchronized whole-interpreter
PyConfigaccess — Concurrent configuration setters and readers produce heap-use-after-free failures in wide-string-list copying and conversion. - Shared itertools combinator advancement — Concurrent
next()calls corrupt mutable state inproduct,combinations,combinations_with_replacement, andpermutations. - Shared
itertools.teecache race — Concurrent advancement can expose an uninitialized shared-cache slot toPy_NewRef, crashing both same-branch and sibling-branch modes. - Managed
__dict__replacement false miss — Attribute lookup can reportAttributeErrorafter inline storage is invalidated even though the replacement dictionary contains the attribute. - OrderedDict borrowed-value promotion race — Fixed-key replacement can reclaim values consumed by
setdefault(),copy(), or values iteration and corrupt the allocator. - OrderedDict unlocked node state — Concurrent structural operations can invalidate the coupled base-dictionary table, fast-node array, and linked nodes during lookup.
partial.__repr__()keyword-dictionary race — Fixed-key replacement can reclaim a borrowed keyword value before formatting promotes it.- Exact-dictionary pickle batching race — Concurrent dictionary mutation can reclaim a borrowed entry before
batch_dict_exactpromotes it, producing an ASan crash. - Exact-list pickle batching race — Concurrent list replacement or resize can reclaim an item before
batch_list_exactpromotes it. pickle.whichmodule()sys.modulesrace — Concurrent synthetic-module replacement can reclaim a borrowed module entry during the fallback scan and crash reference promotion._PyConfig_FromDict()nested-list race — Concurrent mutation ofwarnoptionscan retire a raw list item before its type check and conversion.globals["__builtins__"]replacement race — Evaluation can consume a borrowed builtins object after concurrent replacement frees it, causing stack or mutex corruption.- SQLite converter-registry race — Concurrent public-registry replacement can finalize a borrowed converter before the cursor row-cast map owns it.
str.maketrans()shared-dictionary race — Concurrent clear or replacement can retire borrowed keys and values, producing impossible translation tables or reclaimed objects.warnings.filterslist race — Direct list mutation can finalize a borrowed filter tuple beforeget_filter()inspects and promotes it, producing an ASan crash.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
gvanrossum commentedon Sep 8, 2026
Thank you! That looks like the result of some serious research.
Is there any chance we can convince you to redo your analysis with 3.15 rc2 (which is expected to be virtually identical to the final 3.15.0 release)? And again in free-threading mode, which increases the opportunity for concurrency bugs. Even if we decide not to rush any fixes in 3.15.0, we could fix any of these in follow-up bugfix releases, and backport them as well to 3.14 and 3.13.
In terms of security, I think these are not attack vectors per se. It looks as if they can't be triggered by sending malicious data, but require being able to run Python code; and once an attacker has that ability, they can already do anything that the user they impersonate is allowed to do. Causing a crash of the Python interpreter itself is trivial (
os.kill(os.getpid(), 9)). (But don't trust me on this; a member of Python's security team shouldIn order to prioritize these, we'd have to look at the likelihood that a user just doing their thing would accidentally trigger one of these.
StanFromIreland commentedon Sep 8, 2026
Regarding security, please review possible vulnerabilities against our Security Policy, and submit them if necessary (more information on how to do this is provided in the policy). But from a quick glance I concur with Gudio, they all seem to require executing arbitrary in-process Python code.
Nievesjyl commentedon Sep 8, 2026
Thank you for your response.
I would like to clarify the main concern behind these reports. Regardless of whether these cases ultimately constitute practical attack vectors, ordinary Python-level code should not cause the interpreter itself to crash, corrupt memory, or otherwise fail at the native level.
These cases use ordinary Python operations and public Python APIs, without directly manipulating native memory. Therefore, even if some of them involve complex or concurrent execution patterns, the fact that they can trigger native crashes or memory-safety violations in CPython indicates implementation-level issues that are worth further investigation.
The purpose of these reports is not to claim that every case is necessarily security-exploitable, but rather to identify cases where ordinary Python code can compromise the interpreter's internal stability or memory safety.
In addition, we have tested Python 3.14 and 3.15 as well, and we are currently organizing the corresponding submission materials. We plan to open separate issues for the 3.14 and 3.15 cases. The issues for 3.13, 3.14, and 3.15 will reference each other, and I will also provide a file documenting the issues that are reproducible across all three versions.
I will @mention you in the follow-up issues. If possible, I would appreciate it if you could evaluate this set of issues together with the security team.
Thank you!
gvanrossum commentedon Sep 8, 2026
Sorry, it is up to the security team now. I no longer review PRs, as a general rule.
Nievesjyl commentedon Sep 11, 2026
We are preparing a carefully screened report that complies with CPython policy, so we are closing this issue.