Release Date: | 2025-09-04 | |
Impact: | Moderate | What is this? |
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.
See more information about CVE-2025-38721 from MITRE CVE dictionary and NIST NVD
NOTE: The following CVSS metrics and score provided are preliminary and subject to review.
Base Score: | 4.4 |
Vector String: | CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H |
Version: | 3.1 |
Attack Vector: | Local |
Attack Complexity: | Low |
Privileges Required: | High |
User Interaction: | None |
Scope: | Unchanged |
Confidentiality Impact: | None |
Integrity Impact: | None |
Availability Impact: | High |
Platform | Errata | Release Date |
Oracle Linux version 7 (kernel-uek) | ELSA-2025-20663 | 2025-10-11 |
Oracle Linux version 8 (kernel-uek) | ELSA-2025-20663 | 2025-10-11 |
This page is generated automatically and has not been checked for errors or omissions. For clarification or corrections: