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-144128: Fix crash in array.fromlist with reentrant __index__#144138

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

Conversation

@priyanshu2282-cyber
Copy link
Contributor

@priyanshu2282-cyberpriyanshu2282-cyber commentedJan 22, 2026
edited by bedevere-appbot
Loading

This change fixes a crash inarray.fromlist() that can happen if an element’s__index__ method mutates the input list while it is being processed.
Previously,array.fromlist() assumed the list would remain unchanged during conversion. If__index__ cleared the list, the element being converted could be freed while still in use, leading to a crash. The implementation now keeps the element alive for the duration of the conversion, I have added a regression test to cover this case.

@priyanshu2282-cyber
Copy link
ContributorAuthor

@serhiy-storchaka I have proposed a fix to make array.fromlist() safe against reentrant__index__ calls that mutate the input list, and I have added a regresion test. Please let me know if this approach is appropriate when you have time. Thankyou!

if (!PyLong_Check(v)) {
PyObject *orig_v = v;
Py_INCREF(orig_v);
v = _PyNumber_Index(v);

Choose a reason for hiding this comment

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

I think it would make sense to also passorig_v here. It's technically unnecessary, but it makes the code easier to follow.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

You are right, thanks for pointing it out, from next time I will try to take care of all these stuffs.

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

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

LGTM. I just left minor coding style suggestions.

Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Victor Stinner <vstinner@python.org>
@priyanshu2282-cyber
Copy link
ContributorAuthor

Thanks@vstinner for constant suggestions and changes, your feedback is much appriciated and very helpful for me, I will stick to the format and try not to repeat same mistakes in future.

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

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

LGTM

@vstinnervstinner merged commitdecb25e intopython:mainJan 26, 2026
51 checks passed
@serhiy-storchaka
Copy link
Member

I am not sure this is the right way to fix this issue. Instead of changing some setitems (what about others?), would not it be better to handle this inarray.fromarray() and other methods that pass borrowed references to setters?

There was also other similar array issue.

@vstinner
Copy link
Member

Instead of changing some setitems (what about others?)

I checked the other setters and they don't seem to be vulnerable to the borrowed reference issue. They cannot call arbitrary Python code while using the borrowed reference.

would not it be better to handle this in array.fromarray() and other methods that pass borrowed references to setters?

I'm not sure that it would better, it would be basically the same, but requires to modify more code, no?

There was also other similar array issue.

Would you mind to elaborate?

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@ZeroIntensityZeroIntensityZeroIntensity left review comments

@vstinnervstinnervstinner approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@priyanshu2282-cyber@serhiy-storchaka@vstinner@ZeroIntensity

[8]ページ先頭

©2009-2026 Movatter.jp