CVE-2026-52997

What it actually does

This flaw is a Linux kernel denial-of-service issue in the dualpi2 traffic-control queueing discipline. When the dualpi2 qdisc configuration is changed to reduce packet or memory limits, the kernel may try to dequeue from the wrong internal queue and assume a packet pointer is valid when it is NULL. If packets are present in the L-queue while the C-queue is empty, this can trigger a NULL pointer dereference in kernel context, potentially causing a kernel oops, interface disruption, or full system crash depending on kernel panic settings.

Why it matters to the business

Successful exploitation can make an affected Linux host unstable or unavailable, disrupting workloads, network forwarding, container platforms, or appliances that rely on Linux traffic control. The current exploitation signal is low: EPSS is 0.00126, it is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported. Risk is highest where untrusted users, containers, or automation have CAP_NET_ADMIN or permission to modify Linux qdisc settings.

How an attack unfolds

An attacker first needs the ability to configure Linux traffic control, typically through CAP_NET_ADMIN, root access, privileged container permissions, or a network-management automation path that can run tc commands. The attacker attaches or modifies a dualpi2 qdisc on an interface, generates or classifies traffic so packets accumulate in the L-queue while the C-queue is empty, and then changes the qdisc limit or memlimit to force backlog or memory trimming. In vulnerable kernels, the dualpi2 change handler attempts to dequeue through the root C-queue path and fails to correctly handle the case where no skb is returned. This results in a NULL skb dereference in the kernel, causing a denial of service through a kernel oops or crash.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for dualpi2_change() draining both the C-queue and L-queue safely. No exact fixed package versions were provided, so track vendor advisories and kernel changelogs for this CVE or for the net/sched sch_dualpi2 fix. As mitigations, avoid using the dualpi2 qdisc on affected kernels, remove or replace dualpi2 qdiscs before reducing limit or memlimit values, restrict CAP_NET_ADMIN to trusted users and containers only, avoid privileged containers where possible, and disable unneeded traffic-control modules if operationally feasible.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix, then reboot into the fixed kernel and verify with uname -a and package-manager metadata. Check whether dualpi2 is in use with tc qdisc show and whether the module is loaded with lsmod or modinfo sch_dualpi2. Validate exposure by reviewing whether any users, services, containers, or automation have CAP_NET_ADMIN or can execute tc qdisc change commands. In test environments only, confirm that changing dualpi2 limit or memlimit under queued L-queue traffic no longer produces kernel oops messages or crashes.

Typical attack path

1. Gain local administrative capability, CAP_NET_ADMIN, privileged container access, or control of a network-management component that can modify qdisc settings.
2. Load or use the sch_dualpi2 traffic-control queueing discipline on a network interface.
3. Generate traffic and classification behavior that places packets in the dualpi2 L-queue while the C-queue is empty.
4. Modify the dualpi2 qdisc limit or memlimit to a lower value so the kernel attempts to enforce the new backlog or memory limit.
5. Trigger the vulnerable dequeue path, causing a NULL skb dereference and potential kernel crash or network-service disruption.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, crash dumps, command execution logs, and audit records. Primary sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, systemd-coredump metadata, kdump vmcore analysis, auditd execve records, sudo logs, shell history, EDR telemetry, and container/orchestrator audit events that show NET_ADMIN or privileged containers executing tc. Investigate kernel oops or panic events with stack traces referencing sch_dualpi2, dualpi2_change, qdisc_dequeue_internal, or NULL pointer dereference shortly after tc qdisc change/replace commands. Correlate these events with interface disruptions, unexpected reboots, watchdog resets, or container workloads granted CAP_NET_ADMIN.

• dualpi2_change
• sch_dualpi2
• qdisc_dequeue_internal
• BUG: kernel NULL pointer dereference
• Oops: 0000
• NULL pointer dereference
• tc qdisc add
• tc qdisc change
• tc qdisc replace
• dualpi2
• memlimit
• limit
• CAP_NET_ADMIN
• privileged container
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg

What your security team should do

• Prioritize patching Linux systems that use traffic control, act as routers, gateways, load balancers, Kubernetes/container hosts, network appliances, or allow privileged containers.
• Inventory systems using dualpi2 with tc qdisc show and remove or replace the qdisc on vulnerable kernels until patched.
• Restrict CAP_NET_ADMIN and privileged container use; treat this capability as equivalent to host-impacting administrative access for this vulnerability.
• Review audit, shell history, EDR, and process accounting logs for recent tc qdisc add/change/replace activity involving dualpi2, especially before unexplained kernel oopses or reboots.
• Monitor vendor kernel advisories because exact fixed package versions vary by distribution and were not provided in the input.
• Because EPSS is low and there is no KEV listing or known ransomware use, handle as a targeted local/container escape-to-DoS risk rather than an internet-scale emergency, unless dualpi2 and delegated NET_ADMIN are common in the environment.