CVE-2026-72036

CVE-2026-72036 is a logical desynchronization flaw in sch_multiq, not a traditional memory safety bug. The issue emerges from a specific topology: when a non-work-conserving qdisc like TBF sits between multiq and its child qdisc, the peek operation stashes an skb in the child's gso_skb field, but the subsequent dequeue call retrieves a different packet—orphaning the stash and corrupting qlen and backlog counters. When that corrupted state reaches a QFQ child, the result is a NULL dereference and kernel panic in softirq context, meaning ordinary egress traffic can trigger it without special packets. The fix is straightforward: replace the direct dequeue call with qdisc_dequeue_peeked(), which properly reconciles the peek state. But here's what should concern you: this exact fix was applied to sch_red and sch_sfb in recent patches. Three qdiscs, identical logical error, identical solution. That's not coincidence—that's a pattern. Audit every sch_* implementation in your kernel for direct dequeue calls following peek operations. If a qdisc calls peek() and then calls dequeue() directly rather than through the reconciliation wrapper, it carries this same vulnerability. The topology requirement (non-work-conserving parent + classful child) isn't as restrictive as it sounds—TBF feeding into multiq feeding into classful qdiscs is a standard router configuration. The silent failure mode is worse than the panic: counter drift in qlen and backlog accumulates without triggering a crash, making sustained state corruption possible without any visible symptom until the NULL dereference finally occurs. Prioritize patching systems with any non-work-conserving qdisc (TBF, tbf-based hierarchies) feeding into classful qdiscs under multiq. The exposure window has likely been open since the gso_skb behavior was introduced, and given the three-identical-fixes pattern, other qdiscs almost certainly harbor the same flaw undetected.

Reviewed through automated stages and approved by a human before publication.