CVE-2026-90109: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue
gredenqueue(), bfifoenqueue() and plugenqueue() admit a packet when the current backlog plus the packet length fits within the queue limit:
sch->qstats.backlog + qdiscpktlen(skb) <= sch->limit (gred default VQ) gredbacklog+qdiscpktlen(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdiscpktlen(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug)
sch->qstats.backlog and q->backlog are u32, and qdiscpktlen()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM.
Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps.
The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdiscpktlen, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.110 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.52 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In gred_enqueue(), bfifo_enqueue(), and plug_enqueue(), promote the backlog-plus-packet-length sums to u64 so admission stops when the true backlog exceeds the queue limit.
Event History
Frequently Asked Questions
What level of access is required to trigger this issue?
The issue can only be reproduced by root. Exploitation requires the ability to attach and configure a gred, bfifo, or plug qdisc with a queue limit near 4 GiB.
Are ordinary queue configurations likely to reach the vulnerable condition?
The described trigger requires a true queue backlog exceeding 4 GiB so that 32-bit arithmetic wraps. This requires a limit near 4 GiB and is described as requiring a “ridiculous” setup.
What can be done if an update cannot be applied immediately?
Avoid configuring gred, bfifo, or plug qdiscs with limits near 4 GiB. Keeping queue limits below the 32-bit wrap boundary prevents the described admission-check bypass.