[issue44039] Duplicated assignment in Modules/_randommodule.c

New submission from Brad Larsen : In Modules/_randommodule.c:600, `longval` is used in its own initialization. This seems to be a typo introduced in commit cc0cd43c0f9 for bpo-1635741. 585 static int 586 _random_exec(PyObject *module) 587 { 588 _randomstate *state

[issue44039] Duplicated assignment in Modules/_randommodule.c

Change by Brad Larsen : -- keywords: +patch pull_requests: +24572 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25904 ___ Python tracker <https://bugs.python.org/issu

[issue44039] Duplicated assignment in Modules/_randommodule.c

Brad Larsen added the comment: > Just curious, how did you find this? I am working on some new CodeQL queries (https://securitylab.github.com/tools/codeql/) and saw a warning about this self-assignment from one of the existing queries. LGTM apparently regularly scans cpython: ht

[issue41204] Use of unitialized variable `fields` along error path in code generated from asdl_c.py

New submission from Brad Larsen : In commit b1cc6ba73 from earlier today, an error-handling path can now read an uninitialized variable. https://github.com/python/cpython/commit/b1cc6ba73a51d5cc3aeb113b5e7378fb50a0e20a#diff-fa7f27df4c8df1055048e78340f904c4R695-R697 In particular, asdl_c.py

[issue41697] Heap buffer overflow in the parser

New submission from Brad Larsen : It looks like commit 4a97b1517a6b5ff22e2984b677a680b07ff0ce11 introduced a heap buffer overflow: commit 4a97b1517a6b5ff22e2984b677a680b07ff0ce11 (HEAD -> master, origin/master, origin/HEAD) Author: Pablo Galindo Date: Wed Sep 2 17:44:19 2

[issue41697] Heap buffer overflow in the parser

Brad Larsen added the comment: Nice work with the quick fix! I'm also happy to see the addition of the Linux ASAN builder -- that should help detect memory errors earlier on in the future. -- ___ Python tracker <https://bugs.py

[issue36253] Use after free in ctypes test suite

Brad Larsen added the comment: I was just going to submit a patch for this, then I found this issue. I can confirm; I see the same use-after-free without the fix. -- nosy: +blarsen ___ Python tracker <https://bugs.python.org/issue36

[issue36495] Out-of-bounds array reads in Python/ast.c

New submission from Brad Larsen : There are currently 2 places in Python/ast.c on master where an out-of-bounds array read can occur. Both were introduced with the merge of of typed_ast into CPython in commit dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c (bpo-35766, GH-11645). In both places, the

[issue36496] Local variables can be used uninitialized in _PyPreConfig_Read()

New submission from Brad Larsen : In bpo-36301, in commit f72346c47537657a287a862305f65eb5d7594fbf, a couple possible uses of uninitialized variables were introduced into Python/preconfig.c. In particular, in _PyPreConfig_Read(), along an error-handling path, the `init_utf8_mode` and

[issue36496] Local variables can be used uninitialized in _PyPreConfig_Read()

Change by Brad Larsen : -- keywords: +patch pull_requests: +12576 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36496> ___ ___ Py

[issue13402] Document absoluteness of sys.executable

Brad Larsen added the comment: It looks like sys.executable is *not* always an absolute path. In Python 2.7: $ which python2.7 /opt/local/bin/python2.7 $ cd /opt/local/bin $ ../bin/python2.7 -m 'import sys; print(sys.executable)' /opt/local/bin/../bin/python2.

[issue13402] Document absoluteness of sys.executable

Brad Larsen added the comment: @eryksun, you are right! The output *is* an absolute path as far as `os.path.isabs` is concerned. @ned.deily, you are right about my example --- I transcribed it wrong, and it should be `-c`. The system in question is not a Mac OS system, but a Linux system

[issue24618] Invalid read in PyCode_New

New submission from Brad Larsen: `PyCode_New` can read invalid heap memory. File Objects/codeobject.c: PyCodeObject * PyCode_New(int argcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names

[issue24630] null pointer dereference in `load_newobj_ex`

New submission from Brad Larsen: `load_newobj_ex` in can crash with a null pointer dereference. File Modules/_pickle.c: static int load_newobj_ex(UnpicklerObject *self) { PyObject *cls, *args, *kwargs; PyObject *obj; PickleState *st = _Pickle_GetGlobalState

[issue24630] null pointer dereference in `load_newobj_ex`

Brad Larsen added the comment: Seems to be similar to #24552, but not the same problem. -- ___ Python tracker <http://bugs.python.org/issue24630> ___ ___ Pytho

[issue24630] null pointer dereference in `load_newobj_ex`

Brad Larsen added the comment: Also, it appears that the `ob_type` field of `cls` need not be NULL; it can be an arbitrary value treated as a memory location. Attached another POC that triggers this case. -- Added file: http://bugs.python.org/file39922/bug-nonnull.py

[issue24630] null pointer dereference in `load_newobj_ex`

Brad Larsen added the comment: Both test cases cause segfaults for me: (1) on 64-bit Python 3.4.3 built from source on Mac OS X (2) on the system 64-bit Python 3.4.3 from Debian "Jessie" I do not see the segfaults with a 64-bit build of the latest sources (cpython `default`

[issue24630] null pointer dereference in `load_newobj_ex`

Brad Larsen added the comment: Yeah, this appears to be fixed along with #24552. -- status: open -> pending ___ Python tracker <http://bugs.python.org/issu