CVE-2026-80784 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mptcp: pm : correction d'une fuite de mémoire due à une condition de concurrence lors de l'allocation pendant la phase de désassemblage (teardown)
La fonction `mptcp_pm_destroy()` vide les listes `msk->pm.anno_list` et `msk->pm.userspace_pm_local_addr_list` sous le verrou `msk->pm.lock` durant la fermeture du socket, en relâchant ce dernier entre les deux opérations.
Un gestionnaire ANNOUNCE générique concurrent provenant de l'espace utilisateur (PM) sur le même msk conserve une référence au socket via `mptcp_token_get_sock()` et, dans `mptcp_pm_nl_announce_doit()`, appelle `mptcp_userspace_pm_append_new_local_addr()` ainsi que `mptcp_pm_announced_alloc()`. Ces deux fonctions acquièrent brièvement le verrou `msk->pm.lock` pour ajouter des éléments à leurs listes respectives. Étant donné que le gestionnaire générique conserve une référence au socket, `mptcp_pm_destroy()` peut s'exécuter sur le même msk via `mptcp_disconnect()`, qui invoque `mptcp_destroy_common()` sans décrémenter le compteur de références du socket, avant la fin de l'exécution du gestionnaire.
Si les acquisitions de verrous se produisent dans un ordre tel que `mptcp_pm_destroy()` vide une liste en premier, l'allocation ultérieure ajoute son entrée à une tête de liste sur laquelle aucun autre processus n'itérera pour ce msk, entraînant une fuite mémoire. kmemleak signale des objets `mptcp_pm_add_addr` (provenant de `mptcp_pm_announced_alloc()`) et des objets `mptcp_pm_addr_entry` (provenant de `mptcp_userspace_pm_append_new_local_addr()`) sous une charge soutenue combinant ANNOUNCE concurrents et fermeture, en interaction avec le PM espace utilisateur.
Un bit MPTCP_PM_DESTROYING a été ajouté dans `msk->pm.status`, défini par `mptcp_pm_destroy()` sous pm.lock avant que les listes ne soient vidées, et vérifié sous pm.lock par les chemins d'allocation. Soit l'allocation acquiert le verrou pm.lock en premier, auquel cas son entrée se trouve dans la liste lorsque `mptcp_pm_destroy()` la libère ; soit `mptcp_pm_destroy()` acquiert le verrou pm.lock en premier, auquel cas l'allocation ultérieure détecte ce bit et refuse de procéder.
Ce problème a été identifié par un banc d'essai du flux de protocole MPTCP étendant BRF (arXiv:2305.08782).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.