[ python-Bugs-858016 ] Pathological case segmentation fault in issubclass

[SourceForge.net]

Bugs item #858016, was opened at 2003-12-10 22:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric M. Hopper (omnifarious)
>Assigned to: Brett Cannon (bcannon)
Summary: Pathological case segmentation fault in issubclass

Initial Comment:
This works for the PowerPC Python compiled with gcc 3.3
on OS X using fink.  I suspect it's broader based than
that, but I don't have the ability to check properly.

Here's how to make it segment fault:

x = (basestring,)
for i in xrange(0, 1000000):
   x = (x,)
issubclass(str, x)

At least, it segment faults at the interactive prompt
this way.  I don't know if it does when it's executed
from a file.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-12-13 20:08

Message:
Logged In: YES 
user_id=31435

Yes, this needs to be fixed if it *can* be fixed without heroic 
effort or insane slowdown.  Looks like it can be.

Brett, the missing piece of your worldview <wink> here is that 
anywhere Python can be tricked into segfaulting is a kind 
of "security hole" -- it's not just mistakes we want to protect 
programmers from, we also want to bulletproof against hostile 
users, to the extent sanely possible.

BTW, if issubclass() has this insecurity, I bet isinstance() 
does too (they were introduced & coded at the same time).

----------------------------------------------------------------------

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-11 12:54

Message:
Logged In: YES 
user_id=313

Well, I think any case where the system segment faults
unexpectedly is bad, regardless of how pathological it is.

Personally, I think that issubclass should either have a
recursion limit after which it throws an exception, or it
shouldn't go into sub-tuples at all.

The reason I made this test is that I read the description
of the behavior of issublcass and found it rather strange,
so I decided to push it to see how far it would go.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-12-10 23:28

Message:
Logged In: YES 
user_id=357491

If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you 
will notice that PyObject_IsSubclass goes into a 'for' loop for each 
item in the tuple passed in and calls PyObject_IsSubclass .  
Unfortunately it makes no check for whether the argument it is 
passing is a class itself or not.  This allows it to keep making calls 
as long as the second argument is either a class or a tuple.  This 
is what is leads to the stack being blown and the subsequent 
segfault.

Obvious solution is to put in a check that the argument about to be 
passed is a class itself so as to not have such a deep call chain.  
But since ``help(issubclass)`` actually makes the above use legit 
(it says using a tuple as a second argument is equivalent as 
passing each item to issubclass which is what it is doing, albeit in 
a rather uncommon and pointless way), is it worth putting the 
check in?  Since this is such an obvious mis-use, I say no.  But if 
someone else on python-dev steps in and says otherwise I will 
patch it.

----------------------------------------------------------------------

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-10 22:16

Message:
Logged In: YES 
user_id=313

I forgot this:

Python 2.3.2 (#1, Dec  4 2003, 09:13:58) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470