Bug 2502889 (CVE-2026-64189)

Summary: CVE-2026-64189 kernel: netfilter: ipset: fix race between dump and ip_set_list resize
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerability-draftAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's netfilter ipset component. A race condition exists between the `ip_set_list` resize operation and dump operations. This can lead to a use-after-free vulnerability, where memory is accessed after it has been deallocated. A successful exploitation of this flaw could result in a kernel panic, effectively causing a Denial of Service (DoS) on the system.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-07-20 17:04:03 UTC
In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: fix race between dump and ip_set_list resize

The release path of ip_set_dump_do() and ip_set_dump_done() read
inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.

A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() 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->ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().

  BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
  Read of size 8 at addr ffff88800b5c4018 by task exploit/150
  Call Trace:
   ...
   kasan_report (mm/kasan/report.c:595)
   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
   netlink_dump (net/netlink/af_netlink.c:2325)
   netlink_recvmsg (net/netlink/af_netlink.c:1976)
   sock_recvmsg (net/socket.c:1159)
   __sys_recvfrom (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:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)
  Kernel panic - not syncing: Fatal exception

Comment 4 errata-xmlrpc 2026-08-26 03:58:48 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:59737 https://access.redhat.com/errata/RHSA-2026:59737

Comment 5 errata-xmlrpc 2026-08-26 04:35:28 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:59723 https://access.redhat.com/errata/RHSA-2026:59723

Comment 6 errata-xmlrpc 2026-08-26 05:34:20 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:59821 https://access.redhat.com/errata/RHSA-2026:59821

Comment 7 errata-xmlrpc 2026-09-01 07:31:14 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:61887 https://access.redhat.com/errata/RHSA-2026:61887