CVE-2026-64189: netfilter: ipset: fix race between dump and ip_set_list resize

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

netfilter: ipset: fix race between dump and ipsetlist resize

The release path of ipsetdumpdo() and ipsetdumpdone() read inst->ipsetlist via ipsetrefnetlink(), a plain rcudereferenceraw() of the array pointer. These run from netlinkrecvmsg() without the nfnl mutex and without an RCU read-side critical section.

A concurrent ipsetcreate() can grow the array: it publishes the new array, calls synchronizenet() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronizenet() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free.

The dumped set itself stays pinned via set->refnetlink, so only the array load needs protecting. Take rcureadlock() around it, matching ipsetgetbyname() and ipsetputbyindex().

BUG: KASAN: slab-use-after-free in ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasanreport (mm/kasan/report.c:595) ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) netlinkdump (net/netlink/afnetlink.c:2325) netlinkrecvmsg (net/netlink/afnetlink.c:1976) sockrecvmsg (net/socket.c:1159) sysrecvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1698) Kernel panic - not syncing: Fatal exception