CVE-2023-53200

In the Linux kernel, the following vulnerability has been resolved:

netfilter: x_tables: fix percpu counter block leak on error path when creating new netns

Here is the stack where we allocate percpu counter block:

+-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table

And it can be leaked on this code path:

+-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails

there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table).

Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed). But it's worth fixing even the rare leak.

ctnetlink/x_tables leaked per-CPU rule counter blocks when xt_register_table() failed during network-namespace creation. An attacker would already need CAP_SYS_ADMIN (or equivalent) and to force allocation failure to hit this path. The flaw is a memory-leak only (no C/I impact); practical impact is limited to minor DoS potential from repeated netns setups under memory pressure.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.