Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
Yes, the 2.7 version of _PyEval_SliceIndex would bypass the NULL pointer dereference, so *if* you could make a slice with a NULL stop value, you could trigger a read from uninitialized stack memory, rather than dying due to a NULL pointer dereference. But just like Python 3, 2.7's PySlice_New explicitly replaces all NULLs with None ( https://github.com/python/cpython/blob/2.7/Objects/sliceobject.c#L60 ), so such a slice cannot exist. Since you can't make a slice with a NULL value through any supported API, and any unsupported means of doing this means you already have the ability to execute arbitrary code (and do far worse things that just trigger a read from an uninitialized C stack value), the fact that _PyEval_SliceIndex returns success for v == NULL is irrelevant; v isn't NULL in any code path aside of the specific one documented (the SLICE opcode, gone in Py3, which can pass in NULL, but uses defaults of 0 and PY_SSIZE_T_MAX for low and high respectively, so the silent success just leaves the reasonable defaults set), because all other uses use slice objects as the source for v, and they cannot have NULL values. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35842> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
