Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Show file tree
Hide file tree
Changes from8 commits
Commits
Show all changes
12 commits
Select commitHold shift + click to select a range
e355186
Fix potential null pointer dereference in PySys_AddWarnOptionUnicode
federicovalensoOct 29, 2024
2ca65fe
📜🤖 Added by blurb_it.
blurb-it[bot]Oct 29, 2024
0fb17bc
Update Misc/NEWS.d/next/Security/2024-10-29-09-15-10.gh-issue-126108.…
federicovalensoOct 29, 2024
6c22e44
add assert
federicovalensoOct 29, 2024
6cd01fd
Merge branch 'bug/potential-null-pointer-dereference-in-PySys_AddWarn…
federicovalensoOct 29, 2024
a969026
fix spaces
federicovalensoOct 29, 2024
1667599
fix unbalanced literal markup
federicovalensoOct 29, 2024
9323183
fix backticks
federicovalensoOct 29, 2024
5cd8e30
Update Python/sysmodule.c
federicovalensoOct 29, 2024
f234711
Merge branch 'main' into bug/potential-null-pointer-dereference-in-Py…
federicovalensoOct 30, 2024
67b9de2
Apply suggession for Python/sysmodule.c
federicovalensoOct 31, 2024
7d0754f
Apply suggession for Python/sysmodule.c
federicovalensoOct 31, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
Fix a possible ``NULL`` pointer dereference in :c:func:`!PySys_AddWarnOptionUnicode`.
7 changes: 3 additions & 4 deletionsPython/sysmodule.c
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -2838,6 +2838,7 @@ PySys_ResetWarnOptions(void)
static int
_PySys_AddWarnOptionWithError(PyThreadState *tstate, PyObject *option)
{
assert(tstate != NULL);
PyObject *warnoptions = get_warnoptions(tstate);
if (warnoptions == NULL) {
return -1;
Expand All@@ -2853,11 +2854,9 @@ PyAPI_FUNC(void)
PySys_AddWarnOptionUnicode(PyObject *option)
{
PyThreadState *tstate = _PyThreadState_GET();
if (_PySys_AddWarnOptionWithError(tstate, option) < 0) {
if (tstate &&_PySys_AddWarnOptionWithError(tstate, option) < 0) {
/* No return value, therefore clear error state if possible */
if (tstate) {
_PyErr_Clear(tstate);
}
_PyErr_Clear(tstate);
Copy link
Member

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 maketstate NULL in_PySys_AddWarnOptionWithError.

Copy link
Member

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 wheretstate can beNULL (while interpreter startup / shutdown).

Copy link
Member

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?

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 likePySys_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.

Copy link
ContributorAuthor

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?

Copy link
Member

@picnixzpicnixzOct 31, 2024
edited
Loading

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I thinkassert(tstate != NULL) is fine for the private API.

picnixz reacted with thumbs up emoji
}
}

Expand Down
Loading

[8]ページ先頭

©2009-2025 Movatter.jp