[Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug

[noreply@sourceforge.net]

Bugs item #563303, was opened at 2002-06-01 03:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cliff Owen (cliffo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470