You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Crash in genericaliasobject.c when tuple_extend() fails under allocation failure #155053
While investigating allocation-failure paths in Objects/genericaliasobject.c, I found a NULL dereference in subs_tvars().
When tuple_extend() fails, it returns -1 after _PyTuple_Resize() fails. _PyTuple_Resize() clears its out-parameter (*pv = NULL) on failure, so subargs is guaranteed to be NULL.
However, subs_tvars() unconditionally calls:
if (j<0) {
Py_DECREF(subparams);
Py_DECREF(subargs);
returnNULL;
}
As a result, Py_DECREF(subargs) dereferences a NULL pointer and crashes the interpreter instead of propagating the MemoryError.
tuple_extend() immediately returns -1 when _PyTuple_Resize() fails. _PyTuple_Resize() sets its out-parameter to NULL on failure, so subargs is guaranteed to be NULL when control reaches the error path. Calling Py_DECREF(subargs) therefore dereferences a NULL pointer.
The issue appears related to gh-148222, which removed the same Py_DECREF() pattern from _Py_make_parameters() after _PyTuple_Resize() failure, but this analogous path in subs_tvars() remained unchanged.
Removing Py_DECREF(subargs); causes the reproducer to raise MemoryError instead of crashing.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.16.0a0 (heads/investigate-genericalias-oom-null-decref-dirty:7ce7f0bd851, Aug 1 2026) [GCC 13.3.0]
Activity
pythongh-155053: Address review comments
pythongh-155053: Address review comments