[issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python

2015-11-15 Thread Itai Bar-Natan

New submission from Itai Bar-Natan:

The following embedded application, which calls Py_Main with a "-W X" argument 
where X is not a valid Unicode string, returns a segmentation fault:

```
#include "Python.h"

main() {
wchar_t *invalid_str;
invalid_str = malloc(2*sizeof(wchar_t));
invalid_str[0] = 0x11;
invalid_str[1] = 0;
wchar_t *argv[4] = {L"embedded-python", L"-W", invalid_str, NULL};

Py_Main(3, argv);
}
```

This segmentation fault is present in Python 3.4, 3.5, and the latest 
development branch I downloaded, but is not present in Python 3.2. This program 
is obviously invalid and it may be reasonable to emit a fatal error in this 
situation, but it should not give a segmentation fault.

I believe the issue is that this codes leads to exception being thrown before 
exceptions are initialized, and more specifically, a call to 
PyExceptionClass_Check() within PyErr_Object() reads a NULL pointer. I haven't 
tested this but I expect that this problem would not appear when calling Python 
directly since Python sanitizes the command line arguments from main(). 
Nonetheless even here the possibility of other exceptions being raised early in 
the initialization sequence remains a potential problem.

--
components: Interpreter Core
messages: 254703
nosy: itaibn
priority: normal
severity: normal
status: open
title: Segmentation fault with invalid Unicode command-line arguments in 
embedded Python
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25631>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states

2014-03-26 Thread Itai Bar-Natan

New submission from Itai Bar-Natan:

While browsing the Python source code, I found this suspicious snippet in 
Py_ReprEnter:

dict = PyThreadState_GetDict();
if (dict == NULL)
return 0;

It seems to me like the last line should be return -1;. The way the program 
currently behaves, if PyThreadState_GetDict() fails and returns NULL, 
Py_ReprEnter will fail silently and always report that the input isn't in a 
recursive loop. The correct behavior is to report an error.

It would be difficult to explicitly exhibit this error since it relies on 
another component of Python failing first. One possible way would be to call 
PyObject_Repr on a recursive structure before fully initializing Python. I 
haven't tested this.

Alternately, it's possible that this behavior is intentional because we want 
PyObject_Repr to work for non-self-referential structures even before Python is 
fully initialized (perhaps it could be called during initialization), in 
exchange for a small risk of failure if it is called with a self-referential 
structure before initialization. In that case I suggest that this should be 
pointed out explicitly in the comments to this function.

--
components: Interpreter Core
messages: 214920
nosy: itaibn
priority: normal
severity: normal
status: open
title: Py_ReprEnter potentially misbehaves during malformed thread states
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21073
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com