python / python/cpython

Crash in genericaliasobject.c when tuple_extend() fails under allocation failure

Ouverte
#155,053 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

interpreter-core type-crash
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

Description

Crash report

What happened?

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);
    return NULL;
}

As a result, Py_DECREF(subargs) dereferences a NULL pointer and crashes the interpreter instead of propagating the MemoryError.

Reproducer

A debug build with _testcapi is required.

import _testcapi
from typing import TypeVarTuple

Ts = TypeVarTuple("Ts")
alias = dict[str, tuple[*Ts]]
key = (int, str)

_testcapi.set_nomemory(24, 25)
try:
    alias[key]
finally:
    _testcapi.remove_mem_hooks()

The exact allocation index may vary between builds, so sweeping a range of indices is recommended.

Observed result

ASan reports:

AddressSanitizer: SEGV on unknown address 0x000000000000

#0 _Py_IsImmortal
#1 Py_DECREF
#2 subs_tvars (Objects/genericaliasobject.c)
#3 _Py_subs_parameters
#4 ga_getitem
Root cause

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]

Linked PRs
  • gh-155055

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez dans Objects/genericaliasobject.c, au niveau de subs_tvars() et tuple_extend(), puis exécutez le reproducteur fourni de l'échec d'allocation de _testcapi sur une build de débogage. Vérifiez que le chemin d'échec ne provoque plus de crash et propage MemoryError ; comparez le traitement analogue dans _Py_make_parameters() et examinez le travail lié gh-155055.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
c, python
Domaine
backend
Type d'issue
Bug
Difficulté
2/5
Temps estimé
1-3 heures
Activité
À l'abandon
Clarté
Clairement spécifiée
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.