Wind River Support Network

Description

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

CREATE(Triage):(User=admin) [CVE-2025-38721 (https://nvd.nist.gov/vuln/detail/CVE-2025-38721)