LiveActive security incident?Get immediate response
CVE Record

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

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. 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.

CriticalCVSS 9.8Not KEV-listedUpdated
Glexia's TakeAutomated analysiscritical

Security readout for executives and security teams

Plain-English summary

A Linux Intel Ethernet driver flaw can leak memory pages while receiving multi-buffer network frames, especially with 9K jumbo-frame traffic. Repeated leakage may consume kernel memory and disrupt networking or system availability. The supplied CVSS rating is 9.8, but the technical description documents a resource leak and does not substantiate confidentiality or integrity impact.

Executive priority

Prioritize validation and patching on production systems using ice NICs with jumbo frames or XDP. Availability-sensitive network appliances and high-throughput hosts warrant prompt attention. Do not assume broad remote compromise from the 9.8 score alone; the supplied technical evidence describes memory leakage, while exploitation and confidentiality or integrity consequences remain unproven.

Technical view

The ice driver can skip zero-length receive descriptors when building XDP fragments. Cleanup then iterates by fragment count instead of through next_to_clean, leaving a stale page in the receive ring. Later page reuse can overwrite its reference, producing a page leak. The fix processes every descriptor in the completed multi-buffer frame and carefully adjusts page-count bias after XDP changes.

Likely exposure

Exposure appears limited to Linux systems using the ice network driver and receiving multi-buffer frames. Jumbo frames configured around a 9K MTU are specifically associated with recurring zero-length descriptors. XDP is involved in the affected cleanup path. The supplied version data is internally difficult to reconcile, so confirm exposure against vendor kernels and referenced fixes.

Exploitation context

The bundle marks this CVE as not present in KEV and provides no evidence of active exploitation or a public exploit. The triggering condition can occur during normal jumbo-frame operation. Although the supplied vector says network-accessible and critical, the description establishes a kernel page leak and potential availability impact, not demonstrated code execution or data compromise.

Researcher notes

The affected-version arrays appear inconsistent, including version and commit identifiers with unclear range semantics. Treat them as insufficient for direct fleet matching. The core defect is descriptor-accounting divergence: zero-sized descriptors are excluded from fragment counts but still occupy ring entries. The correction changes cleanup boundaries to next_to_clean and preserves page-count handling when XDP removes tail fragments.

Mitigation direction

  • Apply a vendor kernel containing the referenced ice driver correction.
  • Match vendor kernel builds against the three supplied stable-tree fix commits.
  • If patching is delayed, evaluate disabling jumbo frames where operationally acceptable.
  • Review vendor guidance before changing XDP or NIC configuration.

Validation and detection

  • Confirm whether affected hosts load and actively use the ice driver.
  • Identify interfaces configured for jumbo MTUs and multi-buffer receive traffic.
  • Determine whether XDP programs run on those interfaces.
  • Compare deployed vendor kernels with published advisories and fix backports.
  • Monitor kernel memory growth and network instability under representative defensive testing.
Prepared
Confidence
medium
Sources
5

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-39948 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Critical
CVSS
9.8 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

1CVSS vectors
3Timeline events
0ADP providers
4Source links

CVSS vector scores

1 official score

We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.

ScoreVersionSeverityVectorExploitImpactSource
9.8CVSS 3.1CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H3.95.9Linux

Vulnerability scoring details

Base CVSS 3.1 score

9.8Critical
CVSS 3.1 vector shape for CVE-2025-39948Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux311813ed013c016d4b0b0985a9ee41f778489077, 743bbd93cf29f653fae0e1416a31f03231689911, 743bbd93cf29f653fae0e1416a31f03231689911, ac1728cf370bec2e74fe6a2adf05b4629980d2b3, d445b59d30415bb56f4803f622d566bca06e0abc, 6.12.14, 6.6.78, 6.13.3unaffected
LinuxLinux6.14, 0, 6.12.49, 6.16.9, 6.17affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.