🛡️ CVE-2025-38721 — debian-linux

netfilter: ctnetlink: fix refcount leak on table dump

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.