itertools.zip_longest use-after-free via re-entrant iterator exhaust

[tonghuaroot]

Bug description

itertools.zip_longest has a use-after-free when one iterator's callback re-enters the zip_longest and exhausts a sibling iterator.

zip_longest_next_lock_held() borrows an iterator from lz->ittuple with PyTuple_GET_ITEM (no Py_INCREF), then calls PyIter_Next(it). If that call re-enters and drains the same iterator, the inner call does PyTuple_SET_ITEM(ittuple, i, NULL) + Py_DECREF(it). When the tuple holds the only reference, it is freed while the outer call still uses it.

The reproducer uses filter(None, ...) so the predicate calls bool(item), and del leaves the tuple as the sole owner of the filter:

import itertools, gc

zl_ref = [None]

class CustomIter:
    def __init__(self, data):
        self.data = data
        self.idx = 0
    def __iter__(self):
        return self
    def __next__(self):
        if self.idx >= len(self.data):
            raise StopIteration
        val = self.data[self.idx]
        self.idx += 1
        return val

class Evil:
    armed = True
    def __bool__(self):
        if Evil.armed and zl_ref[0] is not None:
            Evil.armed = False
            try:
                while True:          # re-enter and drain the filter iterator
                    next(zl_ref[0])
            except StopIteration:
                pass
        return False

f = filter(None, CustomIter([Evil() for _ in range(3)]))
zl = itertools.zip_longest(f, range(5), fillvalue=-1)
zl_ref[0] = zl
del f                                # ittuple now owns the only ref to the filter
gc.collect()
print(next(zl))

Run with PYTHONMALLOC=debug python repro.py -> SIGSEGV. With the fix it runs fine.

CPython versions tested on

main

Operating systems tested on

macOS

[brijkapadia]

This issue seems to be a duplicate of #142732,