CVE-2025-38721 in Linux
Summary
by MITRE • 09/04/2025
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix refcount leak on table dump
There is a reference count leak in ctnetlink_dump_table(): if (res < 0) {
nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct;
...
While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.
This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.
This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever.
This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.
One fix would to change this to: if (res < 0) {
if (ct != last) nf_conntrack_get(&ct->ct_general);
But this reference counting isn't needed in the first place. We can just store a cookie value instead.
A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/10/2026
The vulnerability identified as CVE-2025-38721 resides within the Linux kernel's netfilter subsystem, specifically in the ctnetlink component responsible for connection tracking netlink operations. This issue represents a reference count leak that occurs during table dumping operations, creating a persistent memory management problem that can ultimately lead to system instability and resource exhaustion. The flaw manifests in the ctnetlink_dump_table() function where improper reference counting logic creates a scenario that prevents proper cleanup of connection tracking objects, thereby blocking the net namespace dismantling process and module removal operations.
The technical implementation flaw stems from a conditional reference counting mechanism that fails to account for all possible execution paths within the dump operation. When the function encounters a negative result code, it attempts to increment the reference count of a connection tracking object but does not properly consider the case where the current object pointer matches the last processed object pointer. This scenario, while unlikely, creates a situation where the same connection tracking object receives two reference count increments without corresponding decrements, leading to a memory leak that persists until the system reboots or the module is manually unloaded.
The operational impact of this vulnerability extends beyond simple memory consumption, as it creates a cascading failure condition that prevents proper system cleanup operations. The reference count leak specifically prevents the conntrack object from being released, which maintains the cnet->count value above zero and blocks the nf_conntrack_cleanup_net_list() function from completing its operations. This creates a deadlock condition where system resources become permanently tied up, preventing the net namespace from being properly dismantled or the conntrack module from being removed. The vulnerability can be reliably reproduced through automated testing scripts that repeatedly execute connection tracking operations, with the problematic behavior typically manifesting within 20 minutes of continuous operation on preemptible kernels.
The proposed mitigation strategy addresses the immediate issue through a conditional reference counting fix that prevents the double increment by checking whether the current object matches the last processed object before performing the reference count increment. However, the more fundamental solution involves eliminating the reference counting altogether and implementing a cookie-based approach that provides the necessary tracking information without the memory management overhead. This approach aligns with the principle of avoiding unnecessary reference counting in kernel code and follows established best practices for resource management in kernel subsystems. The vulnerability also affects the ctnetlink_exp_dump_table function, indicating a similar flaw that requires identical remediation, and the fix strategy would apply consistently across both functions. This issue relates to CWE-401: Improper Release of Memory Before Removal from Heap and maps to ATT&CK technique T1489: Service Stop, as it creates a persistent system state that prevents proper service cleanup and module removal operations. The root cause demonstrates poor resource management practices in kernel memory allocation and reference counting, which can lead to denial of service conditions and system instability.