New submission from Matt Bandy <matt.ba...@thq.com>: Using the Py_ADDRESS_IN_RANGE macro can result in a crash under certain threading conditions. Since it is intentionally possible for (POOL)->arenaindex to reference memory which is not under Python's control, another thread may modify that memory. In particular, the following sequence of operations is possible and leads to a crash:
1. A thread running Python code enters the Py_ADDRESS_IN_RANGE macro to test a pointer value which was allocated by the system allocator, not the pool-based allocator. 2. That thread intentionally reads a value (POOL)->arenaindex from memory which was not allocated by the Python interpreter. 3. The value (POOL)->arenaindex is tested and is less than maxarenas. 4. An unrelated thread which actually allocated the memory Py_ADDRESS_IN_RANGE is in the middle of looking at modifies the value referenced by (POOL)->arenaindex, changing it to a different value which is larger than maxarenas. 5. The original thread running Python code subscripts arenas with the new value and reads memory past the end of the arenas array, leading to unpredictable behavior or an access violation. It's possible to fix this problem by changing Py_ADDRESS_IN_RANGE to a function so that it reads (POOL)->arenaindex only once, but the adjacent comment suggests that it's important for performance that it be a macro. I observed this crash on Windows Vista x64 using an embedded Python 2.6.4 interpreter, although the same code appears to exist in later versions of Python as well. ---------- components: Interpreter Core messages: 100106 nosy: mbandy severity: normal status: open title: Crash in Py_ADDRESS_IN_RANGE macro versions: Python 2.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8020> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
