CVE-2024-26925

What it actually does

Race condition in nftables commit mutex handling allows premature release during GC sequence, permitting async worker to collect expired objects under inconsistent locking.

Why it matters to the business

Linux systems using nftables may experience kernel instability or denial of service from local workloads, increasing operational risk for servers and containers until kernels are updated.

How an attack unfolds

A local attacker triggers an nftables transaction abort path that temporarily releases the commit mutex before nft_gc_seq_end completes, allowing the GC worker to race and operate on freed state within the same sequence.

How to fix it

Upgrade Linux kernel to commit 2dde18cd1d8fac735875f2e4987f11817cc0bc2c or later equivalent stable release containing the fix; rebuild and reboot systems using affected netfilter code paths.

How to confirm the fix worked

Verify kernel source contains the mutex release moved after nft_gc_seq_end in the abort path; test with nftables workloads that exercise module autoload and GC sequences; confirm no crashes under concurrent transaction abort.

Typical attack path

1. Obtain local code execution on affected Linux system
2. Craft nftables transaction that enters abort path and calls nf_tables_module_autoload
3. Force race between commit mutex release and GC worker collection of expired objects
4. Trigger repeated sequences to induce kernel panic or memory corruption

How to detect it

Review kernel logs for oops or panic entries near nftables GC and commit mutex operations; inspect audit logs for frequent nftables transaction aborts from untrusted processes.

What your security team should do

• Prioritize kernel updates on all systems exposing nftables to untrusted local users
• Monitor vendor advisories for backported fixes in distribution kernels
• Restrict unprivileged nftables access via capabilities or namespaces where possible
• Test upgrades in staging before production rollout due to kernel change impact