CVE-2026-90109 in Linux
Résumé
par VulDB • 18/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: sched : correction du dépassement de capacité (wrap) sur 32 bits pour backlog dans gred, bfifo et plug lors de l'enqueue
gred_enqueue(), bfifo_enqueue() et plug_enqueue() acceptent un paquet lorsque le backlog actuel plus la longueur du paquet tient dans la limite de la file d’attente :
sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (VQ par défaut pour gred) gred_backlog+qdisc_pkt_len(skb) <= q->limit (VQ configurée pour gred) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug)
sch->qstats.backlog et q->backlog sont des u32, et qdisc_pkt_len()/skb->len sont des unsigned int ; toutes les sommes sont donc calculées sur 32 bits et effectuent un wrap à 2^32. Une fois que le backlog réel dépasse 4 GiB, la somme avec wrap devient petite et l’admission continue de réussir, ce qui fait croître la file d’attente sans limite et peut entraîner une situation OOM (Out Of Memory) dans le noyau.
Promouvoir les sommes vers u64 afin que l’admission s’arrête dès que le backlog réel dépasse la limite. La limite étant un u32, la file d’attente bornée reste en dessous de 2^32 et le backlog stocké sous forme de u32 ne subit jamais de wrap.
Le bug ne peut être reproduit qu’en tant que root (bien que cela nécessite une configuration ridicule) : attacher un qdisc gred (ou bfifo/plug) avec une limite proche de 4 GiB, laisser la VQ par défaut non configurée (pour gred), et générer plus de 4 GiB de trafic mis en file d’attente (par exemple via une table de taille / stab pour gonfler qdisc_pkt_len, ou un trafic soutenu à haut débit). La somme u32 backlog+len effectue un wrap à 2^32, l’admission continue de réussir et la file d’attente croît sans limite jusqu’à provoquer un OOM.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.