CVE-2025-38721

What it actually does

Reference count leak in ctnetlink_dump_table() when ct equals last during table dump, causing extra nf_conntrack_get() without corresponding put, preventing conntrack objects from being released and blocking netns dismantle or conntrack module unload in nf_conntrack_cleanup_net_list().

Why it matters to the business

Can lead to system hangs during network namespace cleanup or module removal in Linux environments, disrupting container orchestration, network teardown, or kernel module management; widespread kernel presence increases operational risk despite low exploitability.

How an attack unfolds

A local attacker with low privileges triggers repeated ctnetlink table dumps under conditions where the same conntrack entry is returned consecutively (ct == last), accumulating unreleased references; over time this blocks cleanup paths, with reproduction possible via targeted selftests or fuzzing, though unlikely in normal workloads.

How to fix it

Upgrade affected Linux kernel packages to versions containing commit 586892e341fbf698e7cbaca293e1353957db725a; for listed MinimOS redis components upgrade to 7.2.10-r0; apply the cookie-based skip hint instead of object reference to avoid the leak entirely.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or patched ctnetlink_dump_table logic; run conntrack_resize.sh selftest in a loop to verify no runaway kworker in nf_conntrack_cleanup_net_list(); monitor for successful netns teardown and module unload without hangs.

Typical attack path

1. Obtain local access with privileges to interact with netfilter conntrack
2. Trigger ctnetlink_dump_table() repeatedly to hit the ct == last condition
3. Accumulate leaked references preventing object release
4. Initiate netns dismantle or conntrack rmmod to observe indefinite hang in cleanup

How to detect it

Review kernel logs for indefinite waits in nf_conntrack_cleanup_net_list or spinning kworkers during namespace teardown; inspect conntrack reference counts via debug interfaces for unexpected persistence after dump operations.

What your security team should do

• Prioritize kernel upgrades on systems using netfilter conntrack and containers
• Test patched kernels with network namespace lifecycle workloads before broad deployment
• Monitor for similar refcount issues in ctnetlink_exp_dump_table as noted in the fix
• Apply updates within standard patch cycles given absence from KEV and low EPSS