[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 = get_random_state(module);
589
590 state->Random_Type = PyType_FromModuleAndSpec(
591 module, &Random_Type_spec, NULL);
592 if (state->Random_Type == NULL) {
593 return -1;
594 }
595 if (PyModule_AddType(module, (PyTypeObject *)state->Random_Type) < 0)
{
596 return -1;
597 }
598
599 /* Look up and save int.__abs__, which is needed in random_seed(). */
* 600 PyObject *longval = longval = PyLong_FromLong(0);
601 if (longval == NULL) {
602 return -1;
603 }
604
605 PyObject *longtype = PyObject_Type(longval);
606 Py_DECREF(longval);
607 if (longtype == NULL) {
608 return -1;
609 }
610
611 state->Long___abs__ = PyObject_GetAttrString(longtype, "__abs__");
612 Py_DECREF(longtype);
613 if (state->Long___abs__ == NULL) {
614 return -1;
615 }
616 return 0;
617 }
--
components: Extension Modules
messages: 392949
nosy: blarsen, christian.heimes
priority: normal
severity: normal
status: open
title: Duplicated assignment in Modules/_randommodule.c
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44039>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue44039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://lgtm.com/projects/g/python/cpython Thanks for the quick review. -- ___ Python tracker <https://bugs.python.org/issue44039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is used to generate C source, and when building that
code with Clang 10, there is the attached warning.
Likely fix: initialize `fields` to `NULL`. Also, perhaps a CI loop that has
`-Werror=sometimes-uninitialized` would help detect these.
Compiler warning:
Python/Python-ast.c:1147:9: warning: variable 'fields' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (state == NULL) {
^
Python/Python-ast.c:1210:16: note: uninitialized use occurs here
Py_XDECREF(fields);
^~
./Include/object.h:520:51: note: expanded from macro 'Py_XDECREF'
#define Py_XDECREF(op) _Py_XDECREF(_PyObject_CAST(op))
^~
./Include/object.h:112:41: note: expanded from macro '_PyObject_CAST'
#define _PyObject_CAST(op) ((PyObject*)(op))
^~
Python/Python-ast.c:1147:5: note: remove the 'if' if its condition is always
false
if (state == NULL) {
^~~~
Python/Python-ast.c:1145:35: note: initialize the variable 'fields' to silence
this warning
PyObject *key, *value, *fields;
^
= NULL
1 warning generated.
--
components: Interpreter Core
messages: 372963
nosy: blarsen, vstinner
priority: normal
severity: normal
status: open
title: Use of unitialized variable `fields` along error path in code generated
from asdl_c.py
type: compile error
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41204>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 2020 +0100
bpo-41690: Use a loop to collect args in the parser instead of
recursion (GH-22053)
This program can segfault the parser by stack overflow:
```
import ast
code = "f(" + ",".join(['a' for _ in range(10)]) + ")"
print("Ready!")
ast.parse(code)
```
the reason is that the rule for arguments has a simple recursion when
collecting args:
args[expr_ty]:
[...]
| a=named_expression b=[',' c=args { c }] {
[...] }
If you try building with clang-10 with `--with-pydebug
--with-address-sanitizer`, you should see a crash like the following during the
`generate-posix-vars` step:
=
==39814==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x625000264148 at pc 0x01ff3be8 bp 0x7ffec90e5d00 sp 0x7ffec90e5cf8
READ of size 4 at 0x625000264148 thread T0
#0 0x1ff3be7 in _PyPegen_collect_call_seqs
/build/python/cpython/Parser/pegen.c:2253:61
#1 0x218ab08 in args_rule /build/python/cpython/Parser/parser.c:12240:20
#2 0x20f8906 in arguments_rule
/build/python/cpython/Parser/parser.c:12159:18
#3 0x2158c61 in t_primary_raw
/build/python/cpython/Parser/parser.c:14063:18
#4 0x21416fb in t_primary_rule
/build/python/cpython/Parser/parser.c:13896:22
#5 0x246d944 in single_subscript_attribute_target_rule
/build/python/cpython/Parser/parser.c:13265:18
#6 0x2433a19 in _tmp_20_rule
/build/python/cpython/Parser/parser.c:16717:54
#7 0x24016e3 in assignment_rule
/build/python/cpython/Parser/parser.c:2093:18
#8 0x23e6617 in small_stmt_rule
/build/python/cpython/Parser/parser.c:1526:31
#9 0x2018581 in simple_stmt_rule
/build/python/cpython/Parser/parser.c:1424:18
#10 0x200c22c in statement_rule
/build/python/cpython/Parser/parser.c:1258:32
#11 0x2007026 in _loop1_11_rule
/build/python/cpython/Parser/parser.c:16174:30
#12 0x200455a in statements_rule
/build/python/cpython/Parser/parser.c:1193:18
#13 0x230193f in block_rule
/build/python/cpython/Parser/parser.c:6257:18
#14 0x205886b in function_def_raw_rule
/build/python/cpython/Parser/parser.c:4927:18
#15 0x20229a4 in function_def_rule
/build/python/cpython/Parser/parser.c:4856:37
#16 0x200e2da in compound_stmt_rule
/build/python/cpython/Parser/parser.c:1872:33
#17 0x200a873 in statement_rule
/build/python/cpython/Parser/parser.c:1234:18
#18 0x2007026 in _loop1_11_rule
/build/python/cpython/Parser/parser.c:16174:30
#19 0x200455a in statements_rule
/build/python/cpython/Parser/parser.c:1193:18
#20 0x230193f in block_rule
/build/python/cpython/Parser/parser.c:6257:18
#21 0x2392ac3 in class_def_raw_rule
/build/python/cpython/Parser/parser.c:6196:18
#22 0x202fb74 in class_def_rule
/build/python/cpython/Parser/parser.c:6139:34
#23 0x2010e47 in compound_stmt_rule
/build/python/cpython/Parser/parser.c:1914:30
#24 0x200a873 in statement_rule
/build/python/cpython/Parser/parser.c:1234:18
#25 0x2007026 in _loop1_11_rule
/build/python/cpython/Parser/parser.c:16174:30
#26 0x200455a in statements_rule
/build/python/cpython/Parser/parser.c:1193:18
#27 0x230193f in block_rule
/build/python/cpython/Parser/parser.c:6257:18
#28 0x238f31b in else_block_rule
/build/python/cpython/Parser/parser.c:3787:18
#29 0x204e3c4 in try_stmt_rule
/build/python/cpython/Parser/parser.c:4460:19
#30 0x2014f68 in compound_stmt_rule
/build/python/cpython/Parser/parser.c:1977:29
#31 0x200a873 in statement_rule
/build/python/cpython/Parser/parser.c:1234:18
#32 0x2007026 in _loop1_11_rule
/build/python/cpython/Parser/parser.c:16174:30
#33 0x200455a in statements_rule
/build/python/cpython/Parser/parser.c:1193:18
#34 0x1ff8c93 in file_rule /build/python/cpython/Parser/parser.c:726:18
#35 0x1ff742d in _PyPegen_parse
/build/python/cpython/Parser/parser.c:24794:18
#36 0x1fc1128 in _PyPegen_run_parser
/build/python/cpython/Parser/pegen.c::17
#37 0x1fc5e38 in _PyPegen_run_parser_from_string
/build/python/cpython/Parser/pegen.c:1238:14
#38 0x1a8952b in PyParser_ASTFromStringObject
/build/python/cpython/Parser/peg_api.c:27:21
#39 0x1339bef in Py_CompileStringObject
/build/python/cpython/Python/pythonrun.c:1203:11
#40 0x1f2ac43 in builtin_compile_impl
/build/python/cpython/Pytho
[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.python.org/issue41697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue36253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 out-of-bounds array read occurs when an index variable is
incremented, then used before checking that it is still valid.
The first out-of-bounds read, in `handle_keywordonly_args()`, around line 1403:
case vfpdef:
case tfpdef:
if (i + 1 < NCH(n) && TYPE(CHILD(n, i + 1)) == EQUAL) {
expression = ast_for_expr(c, CHILD(n, i + 2));
if (!expression)
goto error;
asdl_seq_SET(kwdefaults, j, expression);
i += 2; /* '=' and test */
}
else { /* setting NULL if no default value exists */
asdl_seq_SET(kwdefaults, j, NULL);
}
if (NCH(ch) == 3) {
/* ch is NAME ':' test */
annotation = ast_for_expr(c, CHILD(ch, 2));
if (!annotation)
goto error;
}
else {
annotation = NULL;
}
ch = CHILD(ch, 0);
argname = NEW_IDENTIFIER(ch);
if (!argname)
goto error;
if (forbidden_name(c, argname, ch, 0))
goto error;
arg = arg(argname, annotation, NULL, LINENO(ch), ch->n_col_offset,
ch->n_end_lineno, ch->n_end_col_offset,
c->c_arena);
if (!arg)
goto error;
asdl_seq_SET(kwonlyargs, j++, arg);
i += 1; /* the name */
if (TYPE(CHILD(n, i)) == COMMA) /* HERE, OOB read */
i += 1; /* the comma, if present */
break;
The second out-of-bounds read, in `ast_for_arguments()`, around line 1602:
/* ... */
case DOUBLESTAR:
ch = CHILD(n, i+1); /* tfpdef */
assert(TYPE(ch) == tfpdef || TYPE(ch) == vfpdef);
kwarg = ast_for_arg(c, ch);
if (!kwarg)
return NULL;
i += 2; /* the double star and the name */
if (TYPE(CHILD(n, i)) == COMMA) /* HERE, OOB read */
i += 1; /* the comma, if present */
break;
/* ... */
You might see these out-of-bounds reads as crashes at various points during the
build process if you configure as so:
$ clang --version
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ clang++ --version
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ export ASAN_OPTIONS=detect_leaks=0 CC=clang CXX=clang++
$ ./configure --with-address-sanitizer --without-pydebug
$ make # might fail partway through, but a python binary should still be
produced
Finally, to see crashes from the out-of-bounds reads:
$ ./python.exe -c 'def foo(f, *args, kw=None): pass'
=
==59698==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61306740 at pc 0x009aff20 bp 0x7ffe94660260 sp 0x7ffe94660258
READ of size 2 at 0x61306740 thread T0
#0 0x9aff1f in handle_keywordonly_args /cpython/Python/ast.c:1403:21
#1 0x9af034 in ast_for_arguments /cpython/Python/ast.c:1588:31
#2 0x9bb174 in ast_for_funcdef_impl /cpython/Python/ast.c:1748:12
#3 0x99ce99 in PyAST_FromNodeObject /cpython/Python/ast.c:806:25
#4 0x7bc4a2 in PyParser_ASTFromStringObject
/cpython/Python/pythonrun.c:1216:15
#5 0x7ba4cf in PyRun_StringFlags /cpython/Python/pythonrun.c:963:11
#6 0x7ba422 in PyRun_SimpleStringFlags /cpython/Python/pythonrun.c:461:9
#7 0x512c5e in pymain_run_command /cpython/Modules/main.c:220:11
#8 0x512c5e in pymain_run_python /cpython/Modules/main.c:501
#9 0x512c5e in _Py_RunMain /cpython/Modules/main.c:583
#10 0x5144e2 in pymain_main /cpython/Modules/main.c:612:12
#11 0x51485f in _Py_UnixMain /cpython/Modules/main.c:636:12
#12 0x7f62e8f92b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#13 0x437729 in _start (/cpython/python.exe+0x437729)
0x61306740 is located 0 bytes to the right of 384-byte region
[0x613065c0,0x61306740)
allocated by thread T0 here:
#0 0x4e34ef in realloc
/tmp/tmp.XYTE7P6bCb/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165:3
#1 0x8fa635 in PyNode_AddChild /cpython/Parser/node.c:120:22
#2 0x9d16f6 in shift /cpython/Parser/parser.c:114:11
#3 0x9d16f6 in PyParser_AddToken /cpython/Parser/parser.c:285
#4 0x8fbee3 in parsetok /cpython/Parser/parsetok.c:332:14
#5 0x7bc44a in PyParser_ASTFromStringObject
/cpyt
[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 `init_legacy_encoding` variables will be read
uninitialized.
_PyInitError
_PyPreConfig_Read(_PyPreConfig *config, const _PyArgv *args)
{
/* ... */
if (args) {
err = _PyPreCmdline_SetArgv(&cmdline, args);
if (_Py_INIT_FAILED(err)) {
goto done;/* ERROR
HANDLING DONE HERE */
}
}
int init_utf8_mode = Py_UTF8Mode; /*
VARIABLE INITIZLIED HERE */
#ifdef MS_WINDOWS
int init_legacy_encoding = Py_LegacyWindowsFSEncodingFlag;/*
VARIABLE INITIZLIED HERE */
#endif
/* ... */
done:
if (init_ctype_locale != NULL) {
setlocale(LC_CTYPE, init_ctype_locale);
PyMem_RawFree(init_ctype_locale);
}
_PyPreConfig_Clear(&save_config);
Py_UTF8Mode = init_utf8_mode ;/*
UNINITIALIZED READ HERE */
#ifdef MS_WINDOWS
Py_LegacyWindowsFSEncodingFlag = init_legacy_encoding;/*
UNINITIALIZED READ HERE */
#endif
_PyPreCmdline_Clear(&cmdline);
return err;
}
--
components: Interpreter Core
messages: 339268
nosy: blarsen
priority: normal
severity: normal
status: open
title: Local variables can be used uninitialized in _PyPreConfig_Read()
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue36496>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.7 Also in Python 3.5: $ which python3.5 /opt/local/bin/python3.5 $ cd /opt/local/bin $ ../bin/python3.5 -m 'import sys; print(sys.executable)' /opt/local/bin/../bin/python3.5 -- nosy: +blarsen ___ Python tracker <http://bugs.python.org/issue13402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 with newer
Python versions than what come with the system installed to /opt/local. These
are compiled from source, but without any modifications.
I'm commenting here because I'm seeing the `test_sys` test from the regression
suite fail in a slightly modified version of Python that ships with a product.
In particular, in Lib/test/test_sys.py around line 640, we have this:
@unittest.skipIf(sys.base_prefix != sys.prefix,
'Test is not venv-compatible')
def test_executable(self):
# sys.executable should be absolute
self.assertEqual(os.path.abspath(sys.executable), sys.executable)
Yes, /opt/local/bin/../bin/python3.5 is an absolute path as far as
`os.path.isabs` is concerned, but
`os.path.abspath('/opt/local/bin/../bin/python3.5')` gives
'/opt/local/bin/python3.5', and the test fails. So maybe the documentation is
fine but the test is wrong?
--
___
Python tracker
<http://bugs.python.org/issue13402>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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,
PyObject *varnames, PyObject *freevars, PyObject *cellvars,
PyObject *filename, PyObject *name, int firstlineno,
PyObject *lnotab)
{
PyCodeObject *co;
unsigned char *cell2arg = NULL;
Py_ssize_t i, n_cellvars;
// ...
n_cellvars = PyTuple_GET_SIZE(cellvars);
// ...
/* Create mapping between cells and arguments if needed. */
if (n_cellvars) {
Py_ssize_t total_args = argcount + kwonlyargcount +
((flags & CO_VARARGS) != 0) + ((flags & CO_VARKEYWORDS) != 0);
// *** 1 ***
// ...
/* Find cells which are also arguments. */
for (i = 0; i < n_cellvars; i++) {
Py_ssize_t j;
PyObject *cell = PyTuple_GET_ITEM(cellvars, i);
for (j = 0; j < total_args; j++) {
PyObject *arg = PyTuple_GET_ITEM(varnames, j);
// *** 2 ***
if (!PyUnicode_Compare(cell, arg)) {
// *** 3 ***
cell2arg[i] = j;
used_cell2arg = 1;
break;
}
}
}
// ...
}
// ...
}
1. `total_args` is determined from parameters that are user-controlled
(see `r_object` in `Python/marshal.c`, in the `TYPE_CODE` case,
lines 1265--1277).
2. the `varnames` tuple is indexed with a value in the range [0, total_args),
which could be larger than the range of valid indexes for `varnames`.
3. `arg` is now a bogus PyObject value, and causes a segfault in
`PyUnicode_Compare`.
Environment:
$ python3.4 --version
Python 3.4.2
$ uname -a
Linux debian-8-amd64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) x86_64 GNU/Linux
POC:
from marshal import load
from io import BytesIO
payload =
b'\xe3\x01\x00\xff\x00\x00\x00\x00\xfc\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00k\x00\x00|\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x01\xda|x\xa9x\xa9\x00\xe3\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00t\x00\x00|\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x00r\x03\x00\x00\x00\xfa\x0fmk_tesTgases.py\xda\x08\x01\x00\x00\x00s\x00\x00\x00\x00r\x03\x00\x00\x00\xfa\x0fmk_testck_te\x00)\x01\xda\x01x\xa9x\xa9\x00\xe3\x01\x00\x00\x00\x00\x00\x80\x00\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00t\x00\x00"\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x00r\x03\x00\x00\x00\xfa\x0fmk_tMstgases\x11py\xda\x08$\x00\x00\x12s\x00\x00\x00\x00r\x03\x00'
load(BytesIO(payload))
--
components: Interpreter Core
files: invalid_read.py
messages: 246658
nosy: blarsen
priority: normal
severity: normal
status: open
title: Invalid read in PyCode_New
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file39914/invalid_read.py
___
Python tracker
<http://bugs.python.org/issue24618>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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();
// ...
PDATA_POP(self->stack, cls); // *** 1 ***
if (cls == NULL) {
Py_DECREF(kwargs);
Py_DECREF(args);
return -1;
}
if (!PyType_Check(cls)) { // *** 2 ***
Py_DECREF(kwargs);
Py_DECREF(args);
Py_DECREF(cls);
PyErr_Format(st->UnpicklingError,
"NEWOBJ_EX class argument must be a type, not %.200s",
Py_TYPE(cls)->tp_name); // *** 3 ***
return -1;
}
// ...
}
1. `cls` is successfully unpickled, but has an ob_type field set to 0
2. `cls` is determined not to be a `PyType` object
3. `Py_TYPE(cls)` gives a null pointer that is dereferenced via `->tp_name`
Environment:
$ python3.4 --version
Python 3.4.2
$ uname -a
Linux debian-8-amd64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) x86_64 GNU/Linux
POC:
from io import BytesIO
from pickle import load
payload =
b']\x8f\x8f\x8f\x8f\x8f\x8f\x8f\x8fGGbG\x10GGG?GGG:gB(GRUGGhZGGGJGTGCgGG7GB(GRvG\xff\xff\x00\x00GGJGTGhttp://bugs.python.org/file39921/bug.py
___
Python tracker
<http://bugs.python.org/issue24630>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker <http://bugs.python.org/issue24630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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` branch at 231bf0840f8f). Instead, I see an unhandled `_pickle.UnpicklingError`. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue24630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue24630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
