Answer in brief
CVE-2026-90109 records a Unknown severity vulnerability in net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=a3eb95f891d6130b1fc03dd07a8b54cf0a5c8ab8 <3fb51b3960342bbee563543f8d33710fd0fb5a96 || >=a3eb95f891d6130b1fc03dd07a8b54cf0a5c8ab8 <8b2d8c70b969bf84f9e248bfaf2a7135129f2eb6 || >=a3eb95f891d6130b1fc03dd07a8b54cf0a5c8ab8 <d98b92f3d57976ae185238946ec5ea0be32195aa || >=a3eb95f891d6130b1fc03dd07a8b54cf0a5c8ab8 <4c660ee8c809637909f4f7eb1017f7b9401c75c4 | 3fb51b3960342bbee563543f8d33710fd0fb5a96, 8b2d8c70b969bf84f9e248bfaf2a7135129f2eb6, d98b92f3d57976ae185238946ec5ea0be32195aa, 4c660ee8c809637909f4f7eb1017f7b9401c75c4 |
| Linux/Linuxgeneric | 4.2 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.