Repository navigation
Use After Free when assigning into a memoryview #92888
Description
Activity
Tested on 3.12.0 built with./configure --enable-optimizations@vstinner would you class this as a security vuln or just a user bug? IMO it's definitely a bug that we should fix on our end considering memorview promises to raise ValueError after .release. But there exists many ways to corrupt memory in CPython and write to arbitrary addresses (e.g.
ctypesor compiling your own bytecode with maliciousLOAD_FASTinstructions). So I'm not sure if you would class this as a vuln?CC @serhiy-storchaka too for your opinion please.
Nice. Many thanks to you @chilaxan for the reproducer. It only works on non-debug build, but I am sure that it is possible to get the same result on a debug build if slightly change the code.
This is definitely a serious bug, but I am not sure that it can be classified as a practical security vulnerability. Of course the bug can manifest not only with malicious
__index__(it is just a convenient way to reproduce it consistently), but with any__index__implemented in Python if you usememoryviewand multithreading. You only need to be exceptionally (un)lucky to get it. In theory the attacker can attack the program which have all three components (threads, writing tomemoryviewand objects with Python implemented__index__), but it is pure hypothetical scenario.See also #91153 which is a similar bug but with bytearray.
We should fix both but once an attacker can execute this code they have full control already, so not a vulnerability.
Reacted by Erlend E. Aasland and Ken JinHere are simpler examples (they work on debug build):
size = 100 class MyIndex: def __index__(self): m.release() global ba ba = bytearray(size) return 4 ba = None m = memoryview(bytearray(b'\xff'*size)) m[MyIndex()] = 42 print(ba[4]) # prints 42, should be 0 ba = None m = memoryview(bytearray(b'\xff'*size)) m[:MyIndex()] = b'spam' print(ba[:4]) # prints bytearray(b'spam'), should be bytearray(b'\x00\x00\x00\x00') ba = None m = memoryview(bytearray(b'\xff'*size)) m[1] = MyIndex() print(ba[1]) # prints 4, should be 0
Reacted by Erlend E. Aasland@vstinner would you class this as a security vuln or just a user bug?
If you ask me, the exploit makes the assumption than a attacker can execute arbitrary Python code. It doesn't fit into Python Security Model: https://python-security.readthedocs.io/security.html#python-security-model
I consider this issue as a regular bug.
Python doesn't provide any warranty that it's impossible to crash Python with malicious code. Using ctypes you can read/write arbitrary memory.
Reacted by Ken JinVictor, I opened a PR earlier to fix it at #92946. Dang I really hope this didn't cause double work for you.
Oh, I'm not used to the new GitHub UI which lists PR as non-comments but the other thing (notifications? mentions? I don't know how to call it).
- added a commit that references this issue
on Jun 26, 2022 - moved this from Todo to Done in Struct, memoryview and array issues 🏗️
on Jul 13, 2026 - moved this to Todo in Struct, memoryview and array issues 🏗️
on Jul 13, 2026
Bug report
within memoryview.c, I have found two Use After Frees, both based around
memory_ass_sub.The first is if a class with a malicious
__index__method is used as the index for the assignment, its index method is called after the memoryview is checked if it is released. This allows the index method to release the memory view and backing buffer, leading to a write to freed memory when the write completes. The same vuln exists if the class with a malicious index method is used as the assigned value, as its__index__method is called inside ofpack_singleYour environment