Linux Kernel up to 7.1-rc2 peek null pointer dereference

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
5.0$0-$5k0.00

Summaryinfo

A vulnerability marked as critical has been reported in Linux Kernel up to 6.6.139/6.12.87/6.18.29/7.0.6/7.1-rc2. This vulnerability affects the function peek. This manipulation causes null pointer dereference. This vulnerability is registered as CVE-2026-43496. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical was found in Linux Kernel up to 6.6.139/6.12.87/6.18.29/7.0.6/7.1-rc2. Affected by this vulnerability is the function peek. The manipulation with an unknown input leads to a null pointer dereference vulnerability. The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. As an impact it is known to affect availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2026-43496 since 05/01/2026. The exploitation appears to be difficult. Technical details are known, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 316534 (Linux Distros Unpatched Vulnerability : CVE-2026-43496), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.6.140, 6.12.88, 6.18.30, 7.0.7 or 7.1-rc3 eliminates this vulnerability. Applying the patch 36aa34f42cb6842cf371f3a2d3e855d24fd57a50/ce051eede433f876d322ac3550a36a3c6fc4c231/8d09618840b99ef00154d3e731ce9b11e096196d/587dcf970a525f543d8b5855d9f37a4ca97b76ef/458d5615272d3de535748342eb68ca492343048c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (316534) and CERT Bund (WID-SEC-2026-1656). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

  • Google Container-Optimized OS
  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • SUSE openSUSE
  • RESF Rocky Linux
  • Open Source Linux Kernel
  • Proxmox Virtual Environment

Productinfo

Type

Vendor

Name

Version

License

Website

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 5.1
VulDB Meta Temp Score: 5.0

VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔒
VulDB Reliability: 🔍

NVD Base Score: 5.5
NVD Vector: 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: Null pointer dereference
CWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physical: Partially
Local: Yes
Remote: Partially

Availability: 🔒
Status: Not defined

EPSS Score: 🔒
EPSS Percentile: 🔒

Price Prediction: 🔍
Current Price Estimation: 🔒

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Nessus ID: 316534
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2026-43496

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.6.140/6.12.88/6.18.30/7.0.7/7.1-rc3
Patch: 36aa34f42cb6842cf371f3a2d3e855d24fd57a50/ce051eede433f876d322ac3550a36a3c6fc4c231/8d09618840b99ef00154d3e731ce9b11e096196d/587dcf970a525f543d8b5855d9f37a4ca97b76ef/458d5615272d3de535748342eb68ca492343048c

Timelineinfo

05/01/2026 CVE reserved
05/21/2026 +20 days Advisory disclosed
05/21/2026 +0 days VulDB entry created
07/22/2026 +62 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-43496 (🔒)
GCVE (CVE): GCVE-0-2026-43496
GCVE (VulDB): GCVE-100-365005
CERT Bund: WID-SEC-2026-1656 - Linux Kernel: Mehrere Schwachstellen erm&ouml;glichen nicht spezifizierten Angriff

Entryinfo

Created: 05/21/2026 15:21
Updated: 07/22/2026 20:22
Changes: 05/21/2026 15:21 (58), 05/22/2026 15:50 (7), 05/23/2026 05:18 (2), 05/24/2026 07:09 (1), 06/18/2026 20:23 (1), 06/26/2026 21:05 (11), 07/09/2026 04:31 (3), 07/22/2026 20:22 (1)
Complete: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion

No comments yet. Languages: en.

Please log in to comment.

Might our Artificial Intelligence support you?

Check our Alexa App!