Cloudanix VulnDB

CVE-2026-80630

Critical · 9.8

CVSS

9.8

EPSS

0.8%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's network traffic management can cause the whole system to crash when certain packet scheduling settings are used.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

fq_codel calls qdisc_tree_reduce_backlog during peek before reincrementing qlen, allowing qlen to reach zero while a packet remains; this incorrectly triggers the parent's qlen_notify callback, deactivating the class and producing wild memory accesses in dependent schedulers such as qfq.

Why it matters to the business

Kernel crashes or memory corruption can interrupt network traffic shaping on Linux systems, causing denial of service for services that rely on fq_codel or qfq qdiscs and requiring reboots or maintenance windows.

How an attack unfolds

An attacker with the ability to configure or influence qdisc setup sends traffic that forces fq_codel to drop packets during peek; the premature backlog reduction deactivates the parent class, leading to use-after-free or out-of-bounds accesses that manifest as oopses or exploitable memory corruption.

How to fix it

Apply the upstream fix that moves the qdisc_tree_reduce_backlog call until after qlen is restored; rebuild and deploy the corrected kernel. Monitor vendor or distribution advisories for the corresponding package update.

How to confirm the fix worked

Verify the patch is present by inspecting sch_fq_codel.c for the corrected ordering of qlen restoration before qdisc_tree_reduce_backlog; reproduce the original tc/qdisc reset sequence and confirm absence of the reported oops.

Typical attack path

  1. Obtain privileges sufficient to attach or modify qdiscs (local or via container escape)
  2. Attach fq_codel to a network interface and configure parent qdiscs such as qfq
  3. Generate traffic patterns that trigger packet drops inside fq_codel peek
  4. Force qdisc reset or graft operations to execute the faulty qlen_notify path
  5. Trigger kernel oops or memory corruption for denial of service or further exploitation

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oopses referencing qfq_deactivate_agg, qdisc_tree_reduce_backlog, or general protection faults during qdisc reset/graft operations; correlate with tc commands or network namespace activity around the timestamp.

  • qfq_deactivate_agg
  • qdisc_tree_reduce_backlog
  • general protection fault.*qfq
  • RIP:.*qfq_deactivate_agg

What your security team should do

  • Prioritize kernel updates on all systems using fq_codel or qfq qdiscs
  • Restrict unprivileged qdisc configuration via network namespaces or capabilities
  • Enable kernel panic-on-oops and central logging to detect exploitation attempts
  • Review container runtime settings to limit host qdisc manipulation

The record

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever fq_codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though fq_codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a recent report [1] and a wild memory access in qfq: [ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full) [ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216 [ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000 [ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000 [ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024 [ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000 [ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578 [ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000 [ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0 [ 29.376103][ T360] PKRU: 55555554 [ 29.376258][ T360] Call Trace: [ 29.376401][ T360] <TASK> ... [ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057) [ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. [1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/

Affected packages

Ecosystem Package Introduced Fixed