Vulnerabilities

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

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.

  1. 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

  2. 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

  3. 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.