CVE-2025-38721

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: fix refcount leak on table dump<br /> <br /> There is a reference count leak in ctnetlink_dump_table():<br /> if (res ct_general); // HERE<br /> cb-&gt;args[1] = (unsigned long)ct;<br /> ...<br /> <br /> While its very unlikely, its possible that ct == last.<br /> If this happens, then the refcount of ct was already incremented.<br /> This 2nd increment is never undone.<br /> <br /> This prevents the conntrack object from being released, which in turn<br /> keeps prevents cnet-&gt;count from dropping back to 0.<br /> <br /> This will then block the netns dismantle (or conntrack rmmod) as<br /> nf_conntrack_cleanup_net_list() will wait forever.<br /> <br /> This can be reproduced by running conntrack_resize.sh selftest in a loop.<br /> It takes ~20 minutes for me on a preemptible kernel on average before<br /> I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.<br /> <br /> One fix would to change this to:<br /> if (res ct_general);<br /> <br /> But this reference counting isn&amp;#39;t needed in the first place.<br /> We can just store a cookie value instead.<br /> <br /> A followup patch will do the same for ctnetlink_exp_dump_table,<br /> it looks to me as if this has the same problem and like<br /> ctnetlink_dump_table, we only need a &amp;#39;skip hint&amp;#39;, not the actual<br /> object so we can apply the same cookie strategy there as well.