classification
Title: Erroneous Size check in _PyString_Resize
Type: Stage:
Components: None Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, asdfasdfasdfasdfasdfasdfasdf
Priority: normal Keywords:

Created on 2011-11-03 12:50 by asdfasdfasdfasdfasdfasdfasdf, last changed 2011-11-03 13:14 by amaury.forgeotdarc. This issue is now closed.

Messages (3)
msg146927 - (view) Author: david (asdfasdfasdfasdfasdfasdfasdf) Date: 2011-11-03 12:50
The _PyString_Resize function in stringobject.c[0] takes in a PyObject ** and a Py_ssize_t newsize. Where Py_ssize_t is often a typedef for ssize_t(a signed version of size_t). As such the newsize parameter could be negative. 
The code checks for when the newsize is negative like so:

 int
_PyString_Resize(PyObject **pv, Py_ssize_t newsize)
{
...
    if (!PyString_Check(v) || Py_REFCNT(v) != 1 || newsize < 0 ||
        PyString_CHECK_INTERNED(v)) {
        *pv = 0;
        Py_DECREF(v);
        PyErr_BadInternalCall();
        return -1;
    }

Unfortunately, a few lines below it does the following:
 *pv = (PyObject *)
        PyObject_REALLOC((char *)v, PyStringObject_SIZE + newsize);

so now if PyStringObject_SIZE + newsize is enough to wrap around then realloc through python will end up allocating insufficient space for the 'new' string. The python interpreter is likely to crash on this line --> 

    sv->ob_sval[newsize] = '\0';

 
I haven't tried to reproduce this in the python interpreter. 
IMHO the code should be checking that newline + PyStringObject_SIZE is non-negative. 


[0] - http://svn.python.org/projects/python/trunk/Objects/stringobject.c
msg146929 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-11-03 13:02
Let's take an example: on a 32bit system, call
   _PyString_Resize(&s, 0x7ffffff8)
Then PyStringObject_SIZE + newsize is something like -0x7ffffff8 (yes, it wraps around and is a negative number)
But when cast to an unsigned size_t (because that's what PyObject_REALLOC declares as parameter), it becomes 0x80000008, which is correct even if it is very likely to fail.
Did you experience something different?
msg146932 - (view) Author: david (asdfasdfasdfasdfasdfasdfasdf) Date: 2011-11-03 13:12
Yes my bad :-) I got my C test case wrong.
History
Date User Action Args
2011-11-03 13:14:56amaury.forgeotdarcsetstatus: open -> closed
2011-11-03 13:12:58asdfasdfasdfasdfasdfasdfasdfsetstatus: pending -> open

messages: + msg146932
2011-11-03 13:02:37amaury.forgeotdarcsetstatus: open -> pending

nosy: + amaury.forgeotdarc
messages: + msg146929

resolution: not a bug
2011-11-03 12:59:45asdfasdfasdfasdfasdfasdfasdfsettitle: Erroneous Size check in -> Erroneous Size check in _PyString_Resize
2011-11-03 12:59:28asdfasdfasdfasdfasdfasdfasdfsetcomponents: + None
versions: + Python 2.7
2011-11-03 12:50:01asdfasdfasdfasdfasdfasdfasdfcreate