CVE-2025-39948: ice: fix Rx page leak on multi-buffer frames

Published Oct 4, 2025
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

ice: fix Rx page leak on multi-buffer frames

The iceputrxmbuf() function handles calling iceputrxbuf() 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 firstdesc 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 iceputrxmbuf() breaks. Such descriptors get skipped and don't get added as fragments in iceaddxdpfrag. Since the buffer isn't counted as a fragment, we do not iterate over it in iceputrxmbuf(), and thus we don't call iceputrxbuf().

Because we don't call iceputrxbuf(), 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 nexttoalloc.

The icereuserxpage() assumes that the nexttoalloc 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 nexttoalloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The iceputrxmbuf() 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 iceputrxmbuf(), we need to make sure to call iceputrxbuf() on all buffers between firstdesc and nexttoclean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in icegetpgcnts().

Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the nexttoclean element just past the current frame. Unlike i40e, the iceputrxmbuf() function does call iceputrxbuf() on the last buffer of the frame indicating the end of packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecntbias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecntbias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.

The xdpxmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdpxmit pointer argument from iceputrxmbuf(). Instead, set xdpxmit in the icecleanrxirq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated before all calls to icegetpgcnts() or iceputrxmbuf(), as the loop logic requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rxring.

Affected Software

18 affected components
Linux Foundation Linux Kernel
Linux Linux kernel>=6.6.78<6.7
Linux Linux kernel>=6.12.14<6.12.49
Linux Linux kernel>=6.13.3<6.14
Linux Linux kernel>=6.14.1<6.16.9
Linux Linux kernel=6.14
Linux Linux kernel=6.14-rc2
Linux Linux kernel=6.14-rc3
Linux Linux kernel=6.14-rc4
Linux Linux kernel=6.14-rc5
Linux Linux kernel=6.14-rc6
Linux Linux kernel=6.14-rc7
Linux Linux kernel=6.17-rc1
Linux Linux kernel=6.17-rc2
Linux Linux kernel=6.17-rc3
Linux Linux kernel=6.17-rc4
Linux Linux kernel=6.17-rc5
Linux Linux kernel=6.17-rc6

Event History

Oct 4, 2025
CVE Published
via MITRE·07:31 AM
Data Sourced
via MITRE·07:31 AM
DescriptionSeverity
Data Sourced
via NVD·08:15 AM
RemedyDescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2025-39948?

CVE-2025-39948 has a medium severity rating due to the potential for memory leaks in multi-buffer frames.

2

How do I fix CVE-2025-39948?

To fix CVE-2025-39948, update your Linux kernel to the latest version where the vulnerability has been resolved.

3

What does CVE-2025-39948 affect?

CVE-2025-39948 affects the Linux kernel, specifically the ice driver handling for multi-buffer XDP scenarios.

4

Is CVE-2025-39948 exploitable remotely?

CVE-2025-39948 is generally not considered remotely exploitable as it primarily impacts local network operations.

5

When was CVE-2025-39948 reported?

CVE-2025-39948 was reported as a vulnerability in the Linux kernel and resolved in a recent kernel update.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203