From: Jozsef Kadlecsik Date: Thu, 14 May 2026 08:55:10 +0000 (+0200) Subject: netfilter: ipset: fix a potential dump-destroy race X-Git-Tag: v7.1-rc5~40^2~55^2~9 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=53d7fd878c28b28e03769071d1f28ef031a060ad;p=thirdparty%2Fkernel%2Flinux.git netfilter: ipset: fix a potential dump-destroy race When dumping sets in order to create the proper order for restore, the list type of sets dumped last. Therefore internally we run the dumping loop twice: first with all non-list type of sets and skipping the list type ones and then secondly for the list type of sets. Sashiko noticed that there's a potential race between dump and destroy if in the first loop the last set was a list type of set: its pointer remains unreferenced and a concurrent destroy can free it. Fix the issue by resetting the variable holding the pointer. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso --- diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c index c5a26236a0bb8..0874029cb0f2d 100644 --- a/net/netfilter/ipset/ip_set_core.c +++ b/net/netfilter/ipset/ip_set_core.c @@ -1613,6 +1613,7 @@ dump_last: ((dump_type == DUMP_ALL) == !!(set->type->features & IPSET_DUMP_LAST))) { write_unlock_bh(&ip_set_ref_lock); + set = NULL; continue; } pr_debug("List set: %s\n", set->name);