gh-150157: fix: critical section for PyDict_Next in _pickle.c#150158
gh-150157: fix: critical section for PyDict_Next in _pickle.c#150158KowalskiThomas wants to merge 5 commits into
PyDict_Next in _pickle.c#150158Conversation
PyDict_Next in _pickle.cPyDict_Next in _pickle.c
| @@ -0,0 +1,2 @@ | |||
| Fix a heap use-after-free in :mod:`pickle`\'s ``whichmodule`` on | |||
There was a problem hiding this comment.
whichmodule is an internal detail not visible to users. Describe the cause in general words, like it looks from user's point.
There was a problem hiding this comment.
How does the following sound? (I pushed it for now.)
Fix a potential crash occurring when pickling objects
concurrently in free-threaded builds.
Tried to make it clear from and end-user perspective while not sounding too scary (since it's a rare race condition), hence the potential.
There was a problem hiding this comment.
It's not just a matter of luck. There have to be several conditions for this to happen. First, we must pickle by name an object without the __module__ attribute. Second, sys.modules should be concurrently modified (in a specific way, but we will leave this).
There was a problem hiding this comment.
Okay, I feared this might be a little bit too detail-y. I'll rephrase it again 😅
There was a problem hiding this comment.
Updated to this.
Fix a crash in free-threaded builds that occurs when pickling
an object without a ``__module__`` attribute while :data:`sys.modules`
is concurrently being modified.
eb71e46 to
88e8cb8
Compare
88e8cb8 to
3981cfc
Compare
serhiy-storchaka
left a comment
There was a problem hiding this comment.
Technically, this is not correct, most objects do not have such issue even without having __module__, only objects pickled by name (some singletons, named constants or enum-like objects). But if you think that the current wording is enough, we can leave it.
Fixes #150157.
PyDict_Nextin_pickle.c#150157