CVE-2025-38721
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-04

Last updated on: 2025-11-03

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-04
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-09-04
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38721
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux kernel 5.10.244-1
linux kernel 6.1.153-1
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a reference count leak in the Linux kernel's netfilter component, specifically in the ctnetlink_dump_table() function. When an error occurs (res < 0), the code increments the reference count of a connection tracking object (ct) a second time without undoing it if ct is the last object. This causes the connection tracking object to never be released, preventing the count from dropping to zero. As a result, the network namespace dismantle or the conntrack module removal will block indefinitely, causing a runaway kernel worker thread.


How can this vulnerability impact me? :

This vulnerability can cause a kernel worker thread to spin indefinitely, effectively blocking the cleanup of network namespaces or the removal of the conntrack module. This can lead to resource leaks and potentially impact system stability or availability, especially if the conntrack_resize.sh selftest is run repeatedly, as it may take around 20 minutes to trigger the issue on a preemptible kernel.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing a runaway kworker process spinning in nf_conntrack_cleanup_net_list, which may occur after running the conntrack_resize.sh selftest script repeatedly (approximately 20 minutes on a preemptible kernel). Monitoring for such behavior can indicate the presence of the refcount leak.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that fixes the reference count leak in ctnetlink_dump_table by ensuring nf_conntrack_get() is only called when the conntrack object is not the last one, or by using the follow-up patch that replaces the reference counting with a cookie value. Until patches are applied, monitoring and avoiding conditions that trigger the leak (such as repeated conntrack_resize.sh selftest runs) may help reduce impact.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart