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-142663: Fix use-after-free in memoryview comparison#143305

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

Open
superboy-zjc wants to merge3 commits intopython:main
base:main
Choose a base branch
Loading
fromsuperboy-zjc:issue-142663

Conversation

@superboy-zjc
Copy link

@superboy-zjcsuperboy-zjc commentedDec 31, 2025
edited by bedevere-appbot
Loading

When comparing two memoryview objects with different formats,memory_richcompare uses thestruct module to unpack elements. A customstruct.Struct.unpack_from implementation could releases and resizes underlying buffer, which invalidates the buffer pointer, during iteration. This leads to a use-after-free when the comparison loop continued accessing the freed memory.

The fix increments theexports count of the memoryview objects before performing the comparison, effectively locking the buffers. This mirrors the protection already provided for non-memoryview objects viaPyObject_GetBuffer.

When comparing two memoryview objects with different formats, `memory_richcompare` uses the `struct` module to unpack elements. A custom `struct.Struct.unpack_from` implementation could releases and resizes underlying buffer, which invalidates the buffer pointer, during iteration. This leads to a use-after-free when the comparison loop continued accessing the freed memory.The fix increments the `exports` count of the memoryview objects before performing the comparison, effectively locking the buffers. This mirrors the protection already provided for non-memoryview objects via `PyObject_GetBuffer`.
@superboy-zjc
Copy link
Author

All resolved. Thanks for the review!

@picnixzpicnixz self-requested a reviewJanuary 3, 2026 20:43
mv1.release()
src1.append(3.14)
return (1,)
withsupport.swap_attr(struct,"Struct",S):
Copy link
Member

Choose a reason for hiding this comment

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

This line puzzles me a little bit. When you swap classes in the stdlib, you can get unexpected results. Can we replicate this without monkeypatching?

Copy link
Author

Choose a reason for hiding this comment

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

Hi@sobolevn I doubt the possibility of replicating this without monkeypatching. The issue stems from, during a mixed format buffer comparison,memory_richcompare function calls a re-entrantstruct.Struct.unpack_from that is loaded by aPyImport_ImportModuleAttrString("struct", "Struct") call in thestruct_get_unpacker. Is there anyway you would recommend to work around it ?

/* Return a new unpacker for the given format. */staticstructunpacker*struct_get_unpacker(constchar*fmt,Py_ssize_titemsize){    ...// struct.Struct ImportationStruct=PyImport_ImportModuleAttrString("struct","Struct");if (Struct==NULL)returnNULL;x=unpacker_new();    ...x->unpack_from=PyObject_GetAttrString(structobj,"unpack_from");if (x->unpack_from==NULL)        gotoerror;    ...}

Copy link
Member

Choose a reason for hiding this comment

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

There are countless potential issues if we replace stdlib types with something else. Let's please first discuss in the issue whether this is even a valid bug report.

Copy link
Member

Choose a reason for hiding this comment

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

I did consider it as a crash because we also fixed similar occurrences elsewhere. If we just had an exception it would have been ok, but here we have a crash. We do not want this.

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

Reviewers

@sobolevnsobolevnsobolevn left review comments

@picnixzpicnixzAwaiting requested review from picnixz

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@superboy-zjc@sobolevn@picnixz

[8]ページ先頭

©2009-2026 Movatter.jp