homepage

$ cat baderror.py 
class BadError(Exception):
 def __init__(self):
 self.i = 0
 def __hash__(self):
 self.i += 1
 return self.i
e = BadError()
raise e from e
$ ./python.exe -V
Python 3.5.2+
$ ./python.exe baderror.py 
Segmentation fault: 11
I have reproduced this with Python 3.3, 3.4, 3.5, and 3.6; I assume it's been present throughout the 3 series.
This is because print_exception_recursive in pythonrun.c keeps following the __cause__ chain, and here the exception is its own __cause__. It uses a set to ensure that it breaks cycles, but that doesn't help here because of the exception's incorrect __hash__ method.

Is this something that needs to be defended against? My understanding is that it's pretty easy to segfault CPython in a number of ways if you can execute 100% arbitrary code. The only way to cause this problem is if you can define malicious exceptions and cause one to be raised from itself, neither of which occurs in reasonable code.

To my knowledge it is not the kind of arbitrary code which could segfault python code. It is far different for example that the fact by using bytecode magic you can segfault the interpreter, as this last case is explicitly warned in documentation.

Seems it was fixed somewhere between 3.6.3 and 3.6.5+.
Traceback (most recent call last):
 File "baderror.py", line 10, in <module>
 raise e from e
__main__.BadError
3.5 is now in security-only fixes stage, and this doesn't look like a security issue.

It was fixed in issue28603.