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(…

Overview

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.

Affected

• linux_kernel >= 2.6.19, < 5.4.297
• linux_kernel >= 5.5, < 5.10.241
• linux_kernel >= 5.11, < 5.15.190
• linux_kernel >= 5.16, < 6.1.149
• linux_kernel >= 6.2, < 6.6.103
• linux_kernel >= 6.7, < 6.12.43
• linux_kernel >= 6.13, < 6.15.11
• linux_kernel >= 6.16, < 6.16.2
• linux_kernel = 2.6.18
• linux_kernel = 6.17
• debian_linux = 11.0

Remediation

Upgrade past the affected range:

• linux_kernel 6.16.2