[issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c

Ammar Askar report at bugs.python.org
Mon Dec 26 15:17:52 EST 2016


Ammar Askar added the comment:

The proposed patch fixes this, not sure if a regression test is appropriate here.

Here's a more minimal example that demonstrates the exact problem:
```
class Index():
    def __index__(self):
        global a
        a.append("2")
        return 999

a = bytearray(b"1")
buf = buffer(a)
s = buf[:1:Index()] 
# buf[Index():x:x] or buf[x:x:Index()] will also crash
```

The problem doesn't show up when doing buffer[x:Index()] or [Index():x] because this syntax calls the sq_slice method implemented by buffer object which is passed the indexes as numbers.

However when using slice notation with three arguments, the equivilant of these lines of code is executed:
```
slice_object = slice(x, Index(), x)
buffer[slice_object]
```

During the `buffer[slice_object]`, a call is made in the slice object to find the indexes of the slice. This calls into the __index__ method of the Index class which mutates the underlying storage behind the buffer. However, buffer's subscript method stores the underyling storage in a local variable before calling the GetIndices method (assuming the object won't be mutated) which means that when it returns, it returns a pointer to an older portion of memory.

I took a quick look at listobject, stringobject, unicodeobject, tupleobject and bytearrayobject's subscript methods and it seems they all only access their members after the call to PySlice_GetIndices, so I think they should be fine.

memoryview objects cause a `BufferError: Existing exports of data: object cannot be re-sized` error so Py3 should be fine.

----------
keywords: +needs review, patch
nosy: +ammar2
stage:  -> patch review
Added file: http://bugs.python.org/file46046/buffer-use-after-free-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________


More information about the Python-bugs-list mailing list