Strix
26.1K

CVE-2025-38721

MEDIUMCVSS 5.5/10EPSS 0.15%

Last modified

CVE-2025-38721 is a medium-severity vulnerability rated 5.5/10 on the CVSS scale. 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.. EPSS estimates a 0.15% chance of exploitation in the next 30 days.

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.

Metrics

CVSS 3.1
5.5/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS Probability
0.15%

5.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

VendorProductVersionsUpdate
LinuxLinux Kernel>= 2.6.19, < 5.4.297—
LinuxLinux Kernel>= 5.5, < 5.10.241—
LinuxLinux Kernel>= 5.11, < 5.15.190—
LinuxLinux Kernel>= 5.16, < 6.1.149—
LinuxLinux Kernel>= 6.2, < 6.6.103—
LinuxLinux Kernel>= 6.7, < 6.12.43—
LinuxLinux Kernel>= 6.13, < 6.15.11—
LinuxLinux Kernel>= 6.16, < 6.16.2—
LinuxLinux Kernel2.6.18—
LinuxLinux Kernel6.17Rc1
DebianDebian Linux11.0—

References

Timeline

Published
Last Modified
Status
Modified

Frequently Asked Questions

What is 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(): 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.
How severe is CVE-2025-38721?
CVE-2025-38721 has a CVSS score of 5.5/10 (MEDIUM severity). The EPSS model estimates a 0.15% probability of exploitation in the next 30 days.
How do I fix CVE-2025-38721?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

Are you affected by CVE-2025-38721?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST