Uh oh!
There was an error while loading. Please reload this page.
gh-149449: Fix use-after-free in _PyUnicode_GetNameCAPI - #150323
Conversation
Uh oh!
There was an error while loading. Please reload this page.
kumaraditya303
commented
May 24, 2026
I think the simpler alternative to this is to just statically allocate |
The _PyUnicode_Name_CAPI struct was malloc'd per import and freed by
the capsule destructor, leaving the per-interpreter cached pointer
dangling once unicodedata was removed from sys.modules and gc'd. The
\N{...} parser path and the namereplace codec handler then crashed.
Allocate the struct in static storage and drop the destructor; the
contents are immutable function pointers shared across imports.b942917 to
ca33d17CompareUh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
Uh oh!
There was an error while loading. Please reload this page.
Thanks @eendebakpt for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15. |
GH-150352 is a backport of this pull request to the 3.15 branch. |
GH-150353 is a backport of this pull request to the 3.14 branch. |
GH-150354 is a backport of this pull request to the 3.13 branch. |
bedevere-bot
commented
May 24, 2026
|
The cache stored the raw struct pointer extracted from unicodedata's _ucnhash_CAPI capsule without keeping a reference to the owning capsule. Dropping the module from sys.modules and running gc.collect() then freed the struct while \N{...} decoding and the namereplace codec handler were still using it. Hold a strong reference to the capsule on the interpreter state and Py_CLEAR it in _PyUnicode_Fini.
This needs backports I think, as it also affects python versions 3.10 to 3.15.
Claude was used to construct a PR.