Vulnerability · CVE-2025-38721
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():
Published Sep 4, 2025 · catalog updated Oct 19, 2026 · Linux Linux
Check if you run it
No confirmed exploitation is on record for CVE-2025-38721. EPSS is 0.17%. Act only if a listed version of Linux Linux is installed.
Gaps on this record
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
- Severity
- Medium5.5
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- 0.17%
- Remediation
- Version ranges on file
- Affected products
- cpe debian/debian linux · cpe linux/linux kernel · vendor Linux Linux d205dc40798d97d63ad348bfaf7394f445d152d4 <19b909a4b1452fb97e477d2f08b97f8d04095619
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 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 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.
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- cpe debian/debian linux11.0
- cpe linux/linux kernelversion unspecified
- vendor Linux Linux d205dc40798d97d63ad348bfaf7394f445d152d4 <19b909a4b1452fb97e477d2f08b97f8d04095619d205dc40798d97d63ad348bfaf7394f445d152d4 <19b909a4b1452fb97e477d2f08b97f8d04095619
How to fix CVE-2025-38721
Recommended remediation
Affected version ranges suggest a fixed boundary. Verify against the vendor advisory for your release.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
No confirmed exploitation is on record for CVE-2025-38721. EPSS is 0.17%. Act only if a listed version of Linux Linux is installed.
Which versions are affected?
Compare what you have installed with debian/debian linux 11.0; Linux Linux d205dc40798d97d63ad348bfaf7394f445d152d4 <19b909a4b1452fb97e477d2f08b97f8d04095619 d205dc40798d97d63ad348bfaf7394f445d152d4 <19b909a4b1452fb97e477d2f08b97f8d04095619. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
No weakness class is stored. EPSS 0.17%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Sep 4, 2025 · NIST NVD
Detected
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 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 undo
Oct 15, 2026 · NIST NVD
Updated
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 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 undo
Oct 19, 2026 · NIST NVD
Updated
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 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 undo
Sources
- CVE.orgVulnerability recordCVE-2025-38721
Official CVE identifier
cve.org - FIRST EPSSExploitation probabilityCVE-2025-38721
30-day exploitation probability 0.2%
first.org - EUVDVulnerability recordEUVD-2025-26748
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 ct_general); // HERE cb->args[1] = (unsigned long)ct; ... While its very unlikely, its poss
euvd.enisa.europa.eu - NIST NVDVulnerability recordCVE-2025-38721
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 ct_general); // HERE c
nvd.nist.gov
References
Freshness
Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.