CVE-2025-38678

What it actually does

The flaw permits a netfilter nf_tables chain or flowtable update batch to contain duplicate devices; the netdev event path unregisters only the first matching device, leaving the hook for the duplicate unregistered and triggering a WARNING in nf_hook_entry_head during cleanup.

Why it matters to the business

Linux systems running affected kernels, especially container-optimized deployments, may experience kernel warnings, networking instability, or degraded firewall behavior that disrupts container isolation and service availability.

How an attack unfolds

An attacker with sufficient privileges to submit nftables batches (common in container escape scenarios) crafts an update transaction containing duplicate device entries. When the batch is processed the duplicate bypasses validation, the subsequent netdev event unregisters only one hook, and the dangling hook reference can be abused for further privilege escalation, as observed in campaigns such as VMSCAPE and related container-OS kernel exploits.

How to fix it

Update the Linux kernel to a version containing commit 0521e694d5b80899fba8695881a6349f9bc538cb (or later stable backports) which adds the duplicate-device EEXIST check in nf_tables transaction handling.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or a backport that rejects duplicate devices with EEXIST; attempt to reproduce the original batch condition and verify the kernel no longer emits the nf_hook_entry_head WARNING.

Typical attack path

1. Obtain capability to submit nftables transactions (e.g., via container breakout or host access)
2. Construct a batch update that references the same network device twice
3. Submit the batch to trigger the missing duplicate check
4. Trigger netdev events or hook cleanup to surface the unregistered hook
5. Leverage the resulting kernel state for privilege escalation or denial of service

How to detect it

Review kernel logs for the exact WARNING string nf_hook_entry_head+0xaa/0x150 together with nft process activity; correlate with container runtime events and nftables batch submissions from privileged contexts associated with known container-escape actors.

What your security team should do

• Prioritize kernel upgrades on all container-optimized hosts and systems exposing nftables to untrusted workloads
• Monitor EPSS and threat-actor activity for this class of netfilter validation issues
• Apply compensating controls such as seccomp or LSM policies that restrict nftables access where upgrades are delayed