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 <kadlec@netfilter.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index c5a26236a0bb847c4b5c4731aa43c601c6dea26a..0874029cb0f2d333b0189baa2f1dfad7588b5f3c 100644 (file)
--- 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);