https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 18:13:37 +0000 https://vulnerability.circl.lu/vuln/cve-2025-39948 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ice: fix Rx page leak on multi-buffer frames</p> <p>The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.</p> <p>It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.</p> <p>If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don&#39;t get added as fragments in ice_add_xdp_frag. Since the buffer isn&#39;t counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don&#39;t call ice_put_rx_buf().</p> <p>Because we don&#39;t call ice_put_rx_buf(), we don&#39;t attempt to re-use the page or free it. This leaves a stale page in the ring, as we don&#39;t increment next_to_alloc.</p> <p>The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn&#39;t check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page.</p> <p>Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ice: fix Rx page leak on multi-buffer frames</p> <p>The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.</p> <p>It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.</p> <p>If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don&#39;t get added as fragments in ice_add_xdp_frag. Since the buffer isn&#39;t counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don&#39;t call ice_put_rx_buf().</p> <p>Because we don&#39;t call ice_put_rx_buf(), we don&#39;t attempt to re-use the page or free it. This leaves a stale page in the ring, as we don&#39;t increment next_to_alloc.</p> <p>The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn&#39;t check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page.</p> <p>Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0…</p> https://vulnerability.circl.lu/vuln/cve-2025-39948