Issue 1517663: Interpreter crash: filter() + gc.get_referrers() (original) (raw)

Created on 2006-07-05 17:33 by collinwinter, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
fix_filter_crash.patch collinwinter,2006-07-05 17:34 Against r47245
gc_inspection.py.diff collinwinter,2006-07-05 17:46 Against r47245
Messages (4)
msg29053 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-07-05 17:33
Similar to the bug in tuple() shown in the current (r47245) version of Lib/test/crashers/gc_inspection.py, filter() can be exploited in similar ways. Rather than the tricky generator used to exploit tuple(), the attached test case uses a subclass of tuple with a malicious __getitem__ method. The pattern being exploited is the same, however: a built-in function pre-allocates a tuple, then fills it using calls to user-defined code. gc_inspection.py.diff also expands the infrastructure in gc_inspection.py, allowing multiple test functions to run that could crash the interpreter. The second patch, fix_filter_crash.patch, is against Python/bltinmodule.c and adds _PyObject_GC_TRACK/UNTRACK macros around the call to the type's sq_item slot in filtertuple().
msg29054 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-07-05 17:54
Logged In: YES user_id=1344176 An alternative fix for this would be not to invoke filter{tuple,string,unicode} on instances of subclasses of tuple, str and unicode. This would fix this bug because you have to be using a subclass of one of these types to exploit the preallocation. As a side-effect, this would also resolve the issue I raised in bug #1517509 concerning filter()'s treatment of these subtypes re: the iterator protocol.
msg29055 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2006-07-05 18:01
Logged In: YES user_id=80475 FWIW, I think these safe-cracking style efforts at creating crashers is a waste of time. Please focus your efforts on fixing real bugs that matter, not in creating strange self-referential twists designed to poke holes in specific implementation details. There is no end to the kind of things like this that can be found and "fixing" them involves either making the code more convoluted or making the code slower but it won't make life better for most users. Also, I'm concerned that these "fixes" would need to be reviewed with extreme care, lest we introduce some new, real bug that DOES impact people's lives. If there were a real problem with filter(), we would have known it long ago.
msg29056 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-10-12 13:01
Logged In: YES user_id=849994 I will not disagree with Raymond :) Furthermore, with your patch to gc_inspection.py, it doesn't even crash anymore (without the other patch applied).
History
Date User Action Args
2022-04-11 14:56:18 admin set github: 43618
2006-07-05 17:33:57 collinwinter create