CVE-2026-43496
Received Received - Intake
Kernel Panic in Linux Kernel's RED Qdisc with QFQ Child

Publication date: 2026-05-21

Last updated on: 2026-05-21

Assigner: kernel.org

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] <TASK> [ 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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-21
Last Modified
2026-05-21
Generated
2026-05-21
AI Q&A
2026-05-21
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 7.1.0-rc1-00033-g46f74a3f7d57
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's network scheduler, specifically in the red (Random Early Detection) queuing discipline (qdisc) when it has child qdiscs such as qfq (Quick Fair Queueing). The issue arises because the red qdisc incorrectly calls the dequeue() method directly on its child qdisc instead of using the proper qdisc_dequeue_peeked() method after a peek() call. This improper call can lead to a kernel panic due to a null pointer dereference when the child qdisc tries to dequeue packets.

The problem occurs during packet retrieval: the parent qdisc does a peek() to check if the child has packets, and if so, it should dequeue the peeked packet safely. However, the red qdisc calls dequeue() directly, which causes the child qdisc to attempt to dequeue from an internal queue incorrectly, leading to a crash.

The fix replaces the direct dequeue call with the qdisc_dequeue_peeked() method, ensuring safe packet retrieval and preventing kernel panic.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic in the Linux operating system, leading to a system crash or reboot. Such instability can disrupt network operations, cause downtime, and potentially lead to loss of data or service availability.

If exploited or triggered, it could affect systems relying on the affected Linux kernel versions, especially those using the red qdisc with child qdiscs like qfq, impacting network traffic management and overall system reliability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel panic related to the red and qfq queuing disciplines in the Linux kernel. Detection involves monitoring system logs for kernel panic messages or KASAN (Kernel Address Sanitizer) null pointer dereference errors associated with sch_red and sch_qfq modules.

You can check the kernel logs for messages similar to the following, which indicate the vulnerability being triggered:

  • dmesg | grep -i 'KASAN: null-ptr-deref'
  • dmesg | grep -i 'sch_red'
  • dmesg | grep -i 'sch_qfq'

Additionally, monitoring for kernel panics or crashes related to network traffic shaping or queuing disciplines may help detect attempts to exploit this issue.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to update the Linux kernel to a version that includes the patch fixing this vulnerability. The patch replaces the direct dequeue call with a safer peek and qdisc_dequeue_peeked method to prevent kernel panic.

If updating the kernel is not immediately possible, consider disabling or avoiding the use of the red queuing discipline with children qdiscs such as qfq until the patch can be applied.

Monitoring system stability and avoiding network configurations that use the affected queuing disciplines can reduce the risk of triggering the vulnerability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart