cbcvebase.
CVE-2025-39948
published 2025-10-04

CVE-2025-39948: In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling…

PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.27%
19.3th percentile
In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames 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. 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. 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't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. 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't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. 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 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. U

Affected

31 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.16.9-1 (forky)linux 6.16.9-1 (forky)
linuxlinux
linuxlinux
linuxlinux
linuxlinux>= 311813ed013c016d4b0b0985a9ee41f778489077 < 80555adb5c892f0e21d243ae96ed997ee520aea980555adb5c892f0e21d243ae96ed997ee520aea9
linuxlinux>= 6.12.14 < 6.12.496.12.49
linuxlinux>= 6.13.3 < 6.146.14
linuxlinux>= 6.6.78 < 6.76.7
linuxlinux>= 743bbd93cf29f653fae0e1416a31f03231689911 < fcb5718ebfe7fd64144e3399280440cce361a3aefcb5718ebfe7fd64144e3399280440cce361a3ae
linuxlinux>= 743bbd93cf29f653fae0e1416a31f03231689911 < 84bf1ac85af84d354c7a2fdbdc0d4efc8aaec34b84bf1ac85af84d354c7a2fdbdc0d4efc8aaec34b
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.57-16.12.57-1
linuxlinux_kernel>= 0 < 6.16.9-16.16.9-1

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_ubuntu7.8HIGH
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.