CVE-2026-99264 in Linuxinformation

Résumé

par VulDB • 03/11/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

io_uring/net : ne pas réessayer recv sur des tampons non validés (uncommitted)

Le commit 41b70df5b38b (« io_uring/net: valider les tampons partiels lors d'une nouvelle tentative ») valide les tampons fournis par l'anneau lorsqu'une réception doit être réessayée après un transfert partiel, afin qu'une autre requête utilisant le même groupe de tampons ne puisse pas se voir attribuer la mémoire dans laquelle la première continue à recevoir. Il valide le nombre d'octets reçus jusqu'à présent. Cela fonctionne pour un seul tampon qui est consommé en entier, mais la requête conserve tous les espaces qu'elle a mappés :

- Pour une anneau de tampons avec IOU_PBUF_RING_INC, seuls ces octets sont consommés. Le reste du tampon reste à l'en-tête de l'anneau. - Pour un groupe (bundle), seuls les tampons contenant ces octets sont consommés ; ceux qui ont été consultés (peeked) restent dans l'anneau.

Dans les deux cas, la réception suivante avec ce groupe de tampons obtient une mémoire que la requête réessayée continue d'écrire, et celui qui arrive en dernier écrase les données de l'autre. Ce que le retry remplit n'est pas du tout validé, car la liste des tampons n'est plus connue à ce stade. Le noyau la redistribue donc ultérieurement, tandis que le CQE indique à l'application qu'elle a été utilisée, et pour un tampon incrémental, qu'il est terminé avec.

Le reste ne peut pas être validé à l'avance : si la requête finit par recevoir moins de données, il n'y a aucun moyen d'informer l'application que davantage a été consommé que ce dont le CQE fait état. Compléter la demande avec les données reçues plutôt que de la réessayer. MSG_WAITALL n'est plus honoré pour les réceptions dans des tampons incrémentaux ou des groupes multi-tampons ; ils peuvent retourner un compte court, avec la requête marquée comme échouée, comme c'est le cas pour d'autres transferts courts MSG_WAITALL.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsable

Linux

Réserver

25/09/2026

Divulgation

03/11/2026

Modérer

accepté

Entrée

VDB-430249

EPSS

0.00000

KEV

non

Activités

faible

Sources

Do you know our Splunk app?

Download it now for free!