CVE-2026-90109 Affecting linux-6.12 package, versions <6.12.111-1~deb12u1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIAN12-LINUX612-20506685
- published5 Oct 2026
- disclosed17 Sept 2026
Introduced: 17 Sep 2026
NewCVE-2026-90109 (opens in a new tab)How to fix?
Upgrade Debian:12 linux-6.12 to version 6.12.111-1~deb12u1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream linux-6.12 package and not the linux-6.12 package as distributed by Debian.
See How to fix? for Debian:12 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue
gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit:
sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug)
sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/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 qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.
References
- https://security-tracker.debian.org/tracker/CVE-2026-90109
- https://git.kernel.org/stable/c/3fb51b3960342bbee563543f8d33710fd0fb5a96
- https://git.kernel.org/stable/c/4c660ee8c809637909f4f7eb1017f7b9401c75c4
- https://git.kernel.org/stable/c/8b2d8c70b969bf84f9e248bfaf2a7135129f2eb6
- https://git.kernel.org/stable/c/d98b92f3d57976ae185238946ec5ea0be32195aa