-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-126108: Fix potential null pointer dereference in PySys_AddWarnOptionUnicode #126118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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/Security/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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (conditioned to a question) cc @sobolevn
if (tstate) { | ||
_PyErr_Clear(tstate); | ||
} | ||
_PyErr_Clear(tstate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that there's no way to make tstate
NULL in _PySys_AddWarnOptionWithError
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it actually make sense to have _PyErr_Clear
do this automatically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I do some other changes or leave as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also do it in _PySys_AddWarnOptionWithError
? WDYT @ZeroIntensity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think assert(tstate != NULL)
is fine for the private API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_EnsureTstateNotNULL
to 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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@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