Cloudanix VulnDB

CVE-2026-68286

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing bug in the Linux kernel's network drop tracking could let certain network events corrupt memory on older 32-bit computers.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in Linux kernel drop_monitor allows reentrant seqcount corruption during 64-bit per-CPU stats updates when tracepoint probes execute in IRQ context on 32-bit architectures after the drop_queue lock is released.

Why it matters to the business

May cause kernel memory corruption or crashes during network packet drop tracing on 32-bit systems; low immediate operational risk but affects reliability of network monitoring in high-traffic environments.

How an attack unfolds

An attacker triggers repeated network packet drops that invoke the affected tracepoints while a nested interrupt occurs on the same CPU during the unprotected u64_stats update window, leading to inconsistent seqcount state.

How to fix it

Apply the upstream fix that moves the u64_stats_update_begin/inc/end sequence to occur before spin_unlock_irqrestore releases the drop_queue lock; rebuild and deploy the patched kernel.

How to confirm the fix worked

Confirm the u64_stats calls in net_dm_packet_trace_kfree_skb_hit and net_dm_hw_trap_packet_probe now precede the spin_unlock_irqrestore call; test under IRQ load on 32-bit builds.

Typical attack path

  1. Generate network traffic that causes packet drops on a 32-bit Linux system
  2. Invoke drop_monitor tracepoints via kfree_skb or hardware trap paths
  3. Time a nested interrupt to overlap the u64_stats update after lock release
  4. Observe resulting seqcount or stats value corruption

How to detect it

Search kernel logs for oops or warnings referencing seqcount or u64_stats in drop_monitor paths; inspect for unexpected packet drop counter resets after high interrupt activity.

What your security team should do

  • Prioritize patching on all 32-bit Linux kernel deployments using drop_monitor
  • Monitor for kernel oops or stats anomalies in network drop paths
  • Disable drop_monitor tracepoints on unpatched 32-bit systems if feasible

The record

In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.

Affected packages

Ecosystem Package Introduced Fixed