CVE-2026-43496
Description
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked
When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue.
[ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900
The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Linux kernel RED qdisc NULL-deref when child uses qdisc_peek_dequeued; fixed by using peek and qdisc_dequeue_peeked.
Vulnerability
In the Linux kernel's net/sched/sch_red.c, a null-pointer dereference vulnerability exists in the RED (Random Early Detection) qdisc when it has a child qdisc (e.g., qfq) whose peek() callback is qdisc_peek_dequeued(). When a parent qdisc (like TBF) peeks at RED and then dequeues, RED incorrectly calls the child's dequeue directly instead of using a consistent peek-dequeue protocol, leading to a NULL pointer access in the child's dequeue function. This affects kernel versions prior to the inclusion of commits [1] and [2].
Exploitation
An attacker can trigger this vulnerability by sending network traffic through a configured qdisc hierarchy where a RED qdisc is a child of another qdisc (e.g., TBF) and itself has a child qdisc (e.g., qfq) using qdisc_peek_dequeued(). No special privileges are required beyond the ability to send packets. The sequence of operations (peek then dequeue) causes the child's dequeue to be invoked on a NULL pointer, resulting in a kernel panic.
Impact
Successful exploitation causes a kernel panic (denial of service) due to a NULL pointer dereference, as indicated by the KASAN report showing null-ptr-deref in qfq_dequeue. The system becomes unavailable until reboot. No evidence of arbitrary code execution is provided in the description.
Mitigation
The fix is available in upstream Linux kernel commits [1] and [2], which replace the direct dequeue call in RED with a proper peek and qdisc_dequeue_peeked sequence. Users should update their kernel to a version containing these commits. As a workaround, avoid configurations where a RED qdisc with a child using qdisc_peek_dequeued() is placed under another qdisc.
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
108d09618840b9458d5615272d587dcf970a5236aa34f42cb6ce051eede433ce051eede43336aa34f42cb6458d5615272d587dcf970a528d09618840b9Vulnerability mechanics
Root cause
"In RED qdisc, the dequeue callback directly calls the child's dequeue instead of retrieving the skb that was previously stored by the child's peek on the gso_skb queue, leading to a NULL pointer dereference when the child uses qdisc_peek_dequeued()."
Attack vector
An attacker can trigger this vulnerability by crafting network traffic that traverses a RED qdisc configured with a child qdisc (such as QFQ) whose peek() callback is qdisc_peek_dequeued(). When a parent qdisc (e.g., TBF) performs a peek-then-dequeue sequence on the RED qdisc, RED's dequeue calls the child's dequeue directly instead of retrieving the skb from the gso_skb queue. This causes a NULL pointer dereference in the child's dequeue function (e.g., qfq_dequeue), leading to a kernel panic. The attack requires the ability to send network packets through a system with this specific qdisc hierarchy configured.
Affected code
The vulnerability is in the red_dequeue() function within the RED qdisc (net/sched/sch_red.c). The function directly calls the child qdisc's dequeue operation instead of using qdisc_dequeue_peeked() to retrieve the skb that was previously stored by the child's peek on the gso_skb queue. The crash occurs in the child's dequeue function (e.g., qfq_dequeue in sch_qfq) when it dereferences a NULL pointer.
What the fix does
The patch replaces the direct dequeue call in red_dequeue() with qdisc_dequeue_peeked(), which correctly retrieves the skb that was previously stored on the gso_skb queue by the child's peek operation. This ensures that when a parent qdisc performs a peek followed by a dequeue, the RED qdisc returns the same skb that was peeked rather than attempting a new dequeue from the child. The fix aligns RED's behavior with the proper qdisc peek/dequeue semantics used by other qdiscs.
Preconditions
- configRED qdisc must have a child qdisc (e.g., QFQ) whose peek() callback is qdisc_peek_dequeued()
- configA parent qdisc (e.g., TBF) must perform a peek-then-dequeue sequence on the RED qdisc
- networkAttacker must be able to send network packets through the configured qdisc hierarchy
Generated on May 21, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- git.kernel.org/stable/c/36aa34f42cb6842cf371f3a2d3e855d24fd57a50nvd
- git.kernel.org/stable/c/458d5615272d3de535748342eb68ca492343048cnvd
- git.kernel.org/stable/c/587dcf970a525f543d8b5855d9f37a4ca97b76efnvd
- git.kernel.org/stable/c/8d09618840b99ef00154d3e731ce9b11e096196dnvd
- git.kernel.org/stable/c/ce051eede433f876d322ac3550a36a3c6fc4c231nvd
News mentions
0No linked articles in our index yet.