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 ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&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 nfconntrackcleanupnetlist() will wait forever.
This can be reproduced by running conntrackresize.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 nfconntrackcleanupnet_list.
One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&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 ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38721.json"
}