Cloudanix VulnDB

CVE-2026-63983

None

CVSS

—

EPSS

0.2%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux networking flaw can make some systems crash or freeze when they use a risky packet-duplication setup.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This flaw is a denial-of-service condition in the Linux kernel traffic control scheduler, specifically the netem queueing discipline when packet duplication is enabled. Under certain queueing-tree topologies, a duplicated packet can be re-enqueued at the root qdisc and then duplicated again by another netem instance, creating a recursive packet loop. The result can be uncontrolled memory growth, stack exhaustion, soft lockups, kernel panic, or loss of network availability. Exploitation generally requires either the ability to configure traffic control settings, such as CAP_NET_ADMIN or equivalent administrative control, or the presence of an already vulnerable netem configuration that an attacker can drive with traffic.

Why it matters to the business

Affected Linux systems using netem packet duplication can become unstable or unavailable, potentially disrupting network appliances, test environments, CI/CD network simulation jobs, lab infrastructure, virtualized networking hosts, or systems that rely on Linux traffic control for impairment testing. Because this is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, broad opportunistic exploitation is less likely; however, organizations that delegate network administration capabilities to containers, developers, test automation, or multi-tenant workloads should treat it as higher risk because a privileged user or compromised workload could intentionally crash hosts.

How an attack unfolds

An attacker first needs a way to influence Linux traffic control configuration or to send traffic through a host that already has a vulnerable netem hierarchy. In the more direct path, the attacker obtains CAP_NET_ADMIN, root access, or access to an automation path that can run tc commands. They configure multiple netem queueing disciplines in a hierarchy with packet duplication enabled. When traffic is sent through the affected interface, netem duplicates a packet and re-enqueues the copy at the root qdisc. Another netem instance can then process the copy as if it were new and duplicate it again. This can repeat until the kernel consumes excessive memory or stack resources, causing packet-processing stalls, OOM behavior, kernel warnings, lockups, or a crash. In an indirect path, if an administrator has already deployed such a topology for network simulation, a remote party may only need to generate enough matching traffic to trigger the recursive duplication behavior.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream fix for net/sched netem duplicate handling, which marks duplicated packets using skb tc_depth and prevents repeated duplication. If exact fixed package versions are not available from the advisory data, use the latest supported kernel from the operating system or appliance vendor and confirm that the vendor references this issue or the corresponding net/sched netem fix. As interim mitigation, remove or avoid stacked netem qdisc configurations where packet duplication is enabled, disable netem duplicate settings unless strictly required, and restrict who or what can run traffic-control commands. Limit CAP_NET_ADMIN in containers and namespaces, avoid privileged containers where possible, audit CI/test systems that dynamically create qdiscs, and ensure only trusted administrators can alter qdisc configuration.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is updated to a vendor build containing the netem duplicate-loop fix, then reboot into that kernel if required. Inspect active traffic control state with commands such as tc qdisc show and tc class show to identify netem usage and any duplicate percentage settings. Validate that untrusted containers or workloads do not retain CAP_NET_ADMIN or broad privileged mode. In a controlled non-production lab, reproduce the previously vulnerable stacked-netem configuration and confirm that packet duplication no longer recurses, resource usage remains bounded, and the kernel logs do not show soft lockups, stack exhaustion, OOM events, or qdisc-related warnings.

Typical attack path

  1. Gain the ability to configure Linux traffic control, commonly through root, CAP_NET_ADMIN, a privileged container, or misused network-test automation.
  2. Create or abuse an existing qdisc hierarchy that includes multiple netem instances with packet duplication enabled.
  3. Send traffic through the affected interface or class so packets traverse the vulnerable netem path.
  4. Trigger recursive re-enqueueing and repeated duplication of packets.
  5. Cause resource exhaustion, kernel instability, networking failure, or full host denial of service.

How to detect it

To determine whether this was already exploited or accidentally triggered, review kernel logs, audit logs, command history, configuration management logs, CI job logs, and container runtime events for creation of netem qdiscs with duplicate enabled. Focus on timelines where tc qdisc changes are followed by sudden memory pressure, packet storms, soft lockups, kernel warnings, OOM killer activity, watchdog resets, or unexplained host reboots. Useful log sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, auditd execve records for tc, sudo logs, shell history, orchestration logs, and network automation change records. Because there are no known public threat actors or KEV exploitation associated with this issue, detection should emphasize local misuse, compromised privileged workloads, unexpected CAP_NET_ADMIN use, and unstable systems with active netem duplicate configurations.

  • tc qdisc add
  • tc qdisc replace
  • tc qdisc change
  • netem duplicate
  • qdisc netem
  • duplicate 100%
  • duplicate 50%
  • CAP_NET_ADMIN
  • /sbin/tc
  • /usr/sbin/tc
  • /bin/tc
  • /usr/bin/tc
  • Out of memory: Killed process
  • Kernel panic - not syncing
  • soft lockup
  • watchdog: BUG: soft lockup
  • NETDEV WATCHDOG
  • stack overflow
  • kernel BUG at net/sched
  • sch_netem
  • net/sched
  • privileged=true
  • --cap-add=NET_ADMIN

What your security team should do

  • Prioritize patching Linux hosts that use traffic control, netem, network simulation, virtual routing, packet impairment testing, or privileged container networking.
  • Inventory active qdisc configurations and flag any netem duplicate usage, especially stacked or hierarchical netem deployments.
  • Remove unnecessary netem duplicate configurations until patched, particularly on shared, production, or multi-tenant systems.
  • Restrict CAP_NET_ADMIN, privileged containers, and automation paths that can run tc or modify qdisc state.
  • Monitor kernel logs and audit logs for suspicious or unexpected traffic-control changes followed by memory exhaustion, soft lockups, or host instability.
  • For lab and CI systems, review test jobs and scripts that create netem duplicate settings and pin them to patched kernel images.

The record

In the Linux kernel, the following vulnerability has been resolved: net/sched: fix packet loop on netem when duplicate is on When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency.

Affected packages

Ecosystem Package Introduced Fixed