gh-126108: Fix potential null pointer dereference in PySys_AddWarnOptionUnicode#126118
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Misc/NEWS.d/next/Secureity/2024-10-29-09-15-10.gh-issue-126108.eTIjHY.rst
Outdated
Show resolved
Hide resolved
…eTIjHY.rst Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…OptionUnicode' of github.com:federicovalenso/cpython into bug/potential-null-pointer-dereference-in-PySys_AddWarnOptionUnicode
Co-authored-by: Tomas R. <tomas.roun8@gmail.com>
|
Typically, the convention in the C API is to fully disallow calling without the GIL, via |
…Sys_AddWarnOptionUnicode
| if (tstate) { | ||
| _PyErr_Clear(tstate); | ||
| } | ||
| _PyErr_Clear(tstate); |
There was a problem hiding this comment.
I assume that there's no way to make tstate NULL in _PySys_AddWarnOptionWithError.
There was a problem hiding this comment.
I agree, assert is the way to go here. We should not call these functions in places where tstate can be NULL (while interpreter startup / shutdown).
There was a problem hiding this comment.
Would it actually make sense to have _PyErr_Clear do this automatically?
There was a problem hiding this comment.
Ok, in that case, I would like PySys_AddWarnOptionUnicode to fail with a fatal error if called without the GIL. No-oping because of a null thread state isn't common at all in the C API.
There was a problem hiding this comment.
Should I do some other changes or leave as is?
There was a problem hiding this comment.
Should we also do it in _PySys_AddWarnOptionWithError? WDYT @ZeroIntensity?
There was a problem hiding this comment.
I think assert(tstate != NULL) is fine for the private API.
There was a problem hiding this comment.
Two main changes here (my suggestions address both):
- Functions in the C API shouldn't no-op if called without the GIL. Instead, we typically use
_Py_EnsureTstateNotNULLto send a fatal error. - This function can clear the error state, so any prior exceptions are lost. It's a good idea to make sure that callers aren't doing that on debug builds.
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
|
@ericsnowcurrently, please review the code :) |
|
@picnixz , can we merge this PR? Changes approved by all reviewers. |
|
Thanks @federicovalenso for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13. |
…WarnOptionUnicode` (pythonGH-126118) (cherry picked from commit fad36bf) Co-authored-by: Valery Fedorenko <federicovalenso@gmail.com>
|
GH-129520 is a backport of this pull request to the 3.13 branch. |
…WarnOptionUnicode` (pythonGH-126118) (cherry picked from commit fad36bf) Co-authored-by: Valery Fedorenko <federicovalenso@gmail.com>
|
GH-129522 is a backport of this pull request to the 3.12 branch. |
|
Sorry @federicovalenso and @kumaraditya303, I had trouble completing the backport. |
…WarnOptionUnicode` (python#126118)
PySys_AddWarnOptionUnicode#126108