Cyber Resilience

CVE-2025-39948

Linux Kernel 6.6.78 – 6.7

Published
04 October 2025
Modified
30 July 2026
Patch / advisory
CVSS Score v3.1 9.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score 0.0027 19th percentile
Risk Priority 70 floored blend · peak EPSS

Summary

CVE-2025-39948 is a critical-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 19th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

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…

more

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. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() 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 pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias 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 xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() 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 ice_get_pgcnts() or ice_put_rx_mbuf(), 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 rx_ring.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.003 Application Exhaustion Flood Impact
Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-45964Same product: Linux Linux Kernel
CVE-2026-45941Same product: Linux Linux Kernel
CVE-2024-44971Same product: Linux Linux Kernel
CVE-2026-46207Same product: Linux Linux Kernel
CVE-2026-53113Same product: Linux Linux Kernel
CVE-2024-38563Same product: Linux Linux Kernel
CVE-2024-56572Same product: Linux Linux Kernel
CVE-2024-50254Same product: Linux Linux Kernel
CVE-2023-52936Same product: Linux Linux Kernel
CVE-2026-23414Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
6.14, 6.17 · 6.6.78 — 6.7 · 6.12.14 — 6.12.49 · 6.13.3 — 6.14

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.

Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.

Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development can detect unreleased memory, providing partial coverage of the weakness.

prevents

Secure development life cycle mandates memory-management practices that reduce missing-release defects.

prevents

Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.

prevents

Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.

prevents

Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.

finds

Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.

References