CVE-2026-72035 is a NULL pointer dereference in the taprio qdisc that triggers when peeking from a non-work-conserving child qdisc (like QFQ) and then dequeuing directly from that child. The vulnerability stems from a desynchronization between the qdisc's bookkeeping (qlen, backlog) and actual queue state—after tapping peeking, the child stashes the skb in gso_skb, but a direct dequeue call bypasses this stash, leaving counters diverging from reality. The next dequeue finds an empty list and crashes. This occurs from ordinary egress traffic in softirq context, not from crafted packets.
The CVSS score understates the concern. The EPSS score (0.00536) reflects that the bug requires a specific qdisc composition—taprio wrapping non-work-conserving children—that may not be common. But the crash is deterministic once those conditions exist, and the trigger is benign network traffic, not an exploit.
What should worry analysts is the pattern's lineage. This exact antipattern—peeking then directly dequeuing, bypassing the peek state—was previously fixed in sch_red and sch_sfb. Taprio reintroduced it. That means the correct pattern (using qdisc_dequeue_peeked()) exists as a helper function but carries no enforcement weight. The architecture permits both the dangerous and safe calls with equal syntactic validity. Each fix was a local patch, never a subsystem-wide constraint.
Audit taprio and verify whether other qdiscs still use the direct dequeue-after-peek pattern. Beyond that, recognize that counter desynchronization creates blast radius beyond the NULL dereference—any code trusting qlen or backlog as ground truth (pacing, AQM, buffer management) becomes part of the failure chain. The patch fixes taprio but does not commit to a broader audit, leaving the question of whether this antipattern exists elsewhere in the current kernel unanswered.