Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23165
___
New submission from Guido Vranken:
The vulnerability described here is exceedingly difficult to exploit, since
there is no straight-forward way an attacker (someone who controls a Python
script contents but not other values such as system environment variables), can
control a relevant
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23165
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 1ce98e85929d by Benjamin Peterson in branch '3.2':
add some overflow checks before multiplying (closes #23165)
https://hg.python.org/cpython/rev/1ce98e85929d
New changeset d1af6f3a8ce3 by Benjamin Peterson in branch '3.3':
merge 3.2 (closes #23165)
STINNER Victor added the comment:
+size_t argsize = strlen(arg) + 1;
+if (argsize PY_SSIZE_T_MAX/sizeof(wchar_t))
+return NULL;
+res = PyMem_Malloc(argsize*sizeof(wchar_t));
The code doesn't check for integer overflow on +1. I suggest instead:
+size_t arglen =
Benjamin Peterson added the comment:
Presumably strlen can't return SIZE_T_MAX because the trailing '\0' has to have
been allocated somewhere.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23165
STINNER Victor added the comment:
PY_SSIZE_T_MAX is usually smaller than SIZE_T_MAX ;-)
(strlen result is not signed.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23165
___
Benjamin Peterson added the comment:
Right, but there's still no danger of overflow.
On Sun, Jan 4, 2015, at 16:50, STINNER Victor wrote:
STINNER Victor added the comment:
PY_SSIZE_T_MAX is usually smaller than SIZE_T_MAX ;-)
(strlen result is not signed.)
--
