CVE-2026-52984

What it actually does

This is a Linux kernel traffic-control flaw in the netem queuing discipline. When netem is configured to reorder packets, some packets are placed on a separate scheduler queue path that was not included in the configured queue-limit check. As a result, total queued packets can exceed the intended netem limit, potentially causing excessive packet backlog, memory consumption, latency, packet loss, and local or network-facing denial of service on systems using affected netem configurations.

Why it matters to the business

Systems that use Linux netem for traffic shaping, testing, simulation, lab networks, CI environments, network appliances, or containerized network namespaces could experience degraded network performance or service disruption if packet queues grow beyond expected limits. The currently reported exploitation maturity is none, EPSS is low, and it is not listed in CISA KEV, so broad active exploitation is not indicated; however, exposed or multi-tenant environments where untrusted users can configure traffic control should treat this as higher priority.

How an attack unfolds

An attacker first needs a system path where affected Linux netem is in use with packet reordering enabled, or the ability to configure netem themselves through privileges such as CAP_NET_ADMIN in a host or network namespace. They then generate traffic that traverses the affected qdisc and triggers the reorder path. Because reordered packets are not counted in the same queue-length limit used by netem_enqueue(), the attacker can cause total queue occupancy to exceed the configured scheduler limit. Sustained traffic can create unexpected backlog and resource pressure, leading to increased latency, dropped packets, interface instability, or denial of service for traffic using that queue. There is no indication from the supplied data of public exploit maturity, ransomware use, or known threat actor exploitation.

How to fix it

Apply the Linux kernel update that includes the net/sched netem fix to count sch->q.qlen in the queue-limit check. If vendor fixed package versions are not available, use the latest kernel packages from the operating system or appliance vendor that include the upstream fix for this issue. Reboot where required to load the patched kernel. As interim mitigation, avoid using netem packet reordering on production or multi-tenant systems, reduce or remove netem qdisc configurations, restrict CAP_NET_ADMIN and traffic-control access, and prevent untrusted containers or users from configuring qdiscs.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor build containing the netem queue-limit fix, not only that the package is installed. Validate with `uname -r`, vendor package metadata, and kernel changelogs/advisories. Review active qdisc configuration with `tc qdisc show` and `tc -s qdisc show` to identify netem instances using reorder. In a controlled test environment, verify that netem queue length and backlog do not exceed the configured limit when packet reordering is enabled and traffic is generated. Confirm untrusted users and containers do not have CAP_NET_ADMIN unless explicitly required.

Typical attack path

1. Identify a Linux system, container, namespace, lab host, appliance, or CI runner using netem traffic control.
2. Confirm or create a netem qdisc configuration with packet reordering enabled.
3. Send sustained traffic through the affected interface or namespace.
4. Trigger the netem reorder path so packets accumulate outside the queue counter used by the limit check.
5. Cause queue occupancy to exceed the intended limit, producing high backlog, latency, packet loss, memory pressure, or service degradation.

How to detect it

There are no supplied reports of active exploitation or malware-specific artifacts for this vulnerability. Detection should focus on exposure and abuse symptoms. Review shell history, audit logs, EDR telemetry, and process execution logs for unexpected use of `tc qdisc` or netem reordering configuration, especially by non-administrative users, CI jobs, containers, or privileged pods. Inspect active and historical qdisc state with `tc qdisc show` and `tc -s qdisc show`; look for `netem` entries with `reorder` and queue statistics where backlog or qlen is abnormally high relative to the configured limit. Review kernel logs, syslog, journald, container runtime logs, and network monitoring for correlated packet drops, interface watchdog events, memory pressure, OOM kills, soft lockups, or latency spikes during periods of high traffic. In containerized environments, review Kubernetes/container runtime audit data for privileged containers, added NET_ADMIN capability, host networking, or namespace manipulation followed by traffic-control changes.

• tc qdisc add
• tc qdisc change
• tc qdisc replace
• tc qdisc del
• netem
• reorder
• tc -s qdisc
• qdisc netem
• NET_ADMIN
• CAP_NET_ADMIN
• privileged: true
• --cap-add=NET_ADMIN
• --privileged
• hostNetwork: true
• NETDEV WATCHDOG
• Out of memory: Killed process
• soft lockup
• blocked for more than
• qdisc
• backlog
• drops
• overlimits

What your security team should do

• Inventory Linux systems and network namespaces using netem, especially where `reorder` is configured.
• Prioritize patching systems where untrusted users, containers, CI jobs, or tenants can use CAP_NET_ADMIN or configure traffic control.
• Apply vendor kernel updates and reboot into the fixed kernel.
• Temporarily remove or disable netem packet reordering on production, shared, or externally reachable paths until patched.
• Restrict access to `tc`, CAP_NET_ADMIN, privileged containers, and network namespace administration.
• Monitor qdisc statistics, kernel logs, and interface telemetry for unusual backlog, packet drops, latency spikes, soft lockups, or memory pressure.
• Because EPSS is low and there is no KEV listing or known exploit maturity, handle as a targeted hardening and availability risk rather than an emergency internet-wide exploitation event unless local exposure is high.