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:39 | jnferguson | set | spambayes_score: 0.00946836 -> 0.009468357 recipients: + jnferguson |
| 2008年04月11日 22:35:38 | jnferguson | set | spambayes_score: 0.00946836 -> 0.00946836 messageid: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za> |
| 2008年04月11日 22:35:36 | jnferguson | link | issue2620 messages |
| 2008年04月11日 22:35:35 | jnferguson | create | |