This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jnferguson
Recipients jnferguson
Date 2008-04-11.22:35:34
SpamBayes Score 0.009468357
Marked as misclassified No
Message-id <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
In-reply-to
Content
174 static
 175 int unicode_resize(register PyUnicodeObject *unicode,
 176                       Py_ssize_t length)
 177 {
 [...]
 201 
 202     oldstr = unicode->str;
 203     PyMem_RESIZE(unicode->str, Py_UNICODE, length + 1);
[...]
 209     unicode->str[length] = 0;
 210     unicode->length = length;
 211  

 95 #define PyMem_RESIZE(p, type, n) \
 96   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 97         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )

The unicode_resize() function acts essentially as a wrapper to
realloc(), it accomplishes this via the PyMem_RESIZE() macro which
factors the size with the size of the type, in this case it multiplies
by two as Py_UNICODE is typedef'd to a wchar_t. When resizing large
strings, this results in an incorrect allocation that in turn leads to
buffer overflow.

This is specific to the Unicode objects, however I would not be
surprised to see that other types have this complication as well. Please
see attached proof of concepts.
History
Date User Action Args
2008-04-11 22:35:39jnfergusonsetspambayes_score: 0.00946836 -> 0.009468357
recipients: + jnferguson
2008-04-11 22:35:38jnfergusonsetspambayes_score: 0.00946836 -> 0.00946836
messageid: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
2008-04-11 22:35:36jnfergusonlinkissue2620 messages
2008-04-11 22:35:35jnfergusoncreate