NULL Pointer Dereference Affecting kernel-zfcpdump-devel-matched package, versions *


Severity

Recommended
0.0
medium
0
10

Based on CentOS security rating.

Threat Intelligence

EPSS
0.16% (7th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS10-KERNELZFCPDUMPDEVELMATCHED-18922526
  • published19 Aug 2026
  • disclosed15 Aug 2026

Introduced: 15 Aug 2026

NewCVE-2026-72036  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 kernel-zfcpdump-devel-matched.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel-matched package and not the kernel-zfcpdump-devel-matched package as distributed by Centos. See How to fix? for Centos:10 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked

multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress.

Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.

CVSS Base Scores

version 3.1