CVE-2026-74492 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: do not update comments from kernel-side hash adds
mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer.
If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer.
Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's netfilter subsystem specifically in the ipset module where a race condition occurs during hash table resizing operations. The flaw stems from improper handling of comment pointer management during table swaps and backlog replay processes. When mtype_resize() function executes, it uses memcpy() to copy comment pointers rather than duplicating the actual comment objects themselves. This creates a scenario where the old table remains accessible for packet-side updates while the new table already contains entries with copied pointer references.
The operational impact becomes critical during the transitional window between table swap completion and backlog replay execution. During this period, packet-side operations can still access the old table structure while the replacement table has already been updated with copied comment pointers. When xt_SET command with --add-set and --exist options encounters an entry in this vulnerable window, mtype_add() function incorrectly calls ip_set_init_comment() even though packet-side additions do not carry comment payload data. This erroneous function call frees memory associated with the shared comment storage through the old table entry.
The vulnerability manifests when the replacement table entry ends up holding a stale pointer reference after the original comment storage has been freed. Subsequently, when the queued add operation is replayed against the new table structure, mtype_add() again invokes ip_set_init_comment() which then attempts to perform strlen() operations on the already-freed stale pointer. This results in memory corruption and potential system instability.
This issue represents a classic case of improper resource management and race condition handling within kernel space networking components. The vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-416 (Use After Free) categories. From an attack perspective, this could potentially enable privilege escalation or denial of service conditions depending on exploitation vectors. The fix implements proper conditional logic in mtype_add() to skip ip_set_init_comment() calls when ext->target indicates packet-side additions, ensuring that userspace operations continue to update comments while preventing packet-side operations from inadvertently freeing shared memory resources.
The solution addresses fundamental synchronization issues between kernel-side hash table management and packet processing pathways. This approach prevents the scenario where multiple code paths attempt to manage the same memory resource concurrently, thereby maintaining data integrity during dynamic table resizing operations. The patch essentially establishes clear boundaries between different operational contexts within the ipset subsystem, ensuring that memory management decisions are appropriately scoped to their respective usage patterns.