https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 09 Oct 2026 08:47:48 +0000 https://cve.radiocsirt.org/vuln/cve-2024-26924 <p><strong>Affected:</strong> Linux, linux_kernel</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nft_set_pipapo: do not free live element</p> <p>Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:</p> <p>add_elem(&#34;00000000&#34;) timeout 100 ms ... add_elem(&#34;0000000X&#34;) timeout 100 ms del_elem(&#34;0000000X&#34;) &lt;---------------- delete one that was just added ... add_elem(&#34;00005000&#34;) timeout 100 ms</p> <p>1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.</p> <p>Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.</p> <p>Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.</p> <p>The _remove function does not work correctly if we have more than one element that share the same key.</p> <p>This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.</p> <p>In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.</p> <p>The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer)…</p> <p><strong>Affected:</strong> Linux, linux_kernel</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nft_set_pipapo: do not free live element</p> <p>Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:</p> <p>add_elem(&#34;00000000&#34;) timeout 100 ms ... add_elem(&#34;0000000X&#34;) timeout 100 ms del_elem(&#34;0000000X&#34;) &lt;---------------- delete one that was just added ... add_elem(&#34;00005000&#34;) timeout 100 ms</p> <p>1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.</p> <p>Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.</p> <p>Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.</p> <p>The _remove function does not work correctly if we have more than one element that share the same key.</p> <p>This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.</p> <p>In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.</p> <p>The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer)…</p> https://cve.radiocsirt.org/vuln/cve-2024-26924