SecOps SignalSecurity Intelligence Workspace
Loading collection status
Vulnerabilities/CVE-2025-39948Public Intelligence Dossier
Source: linux · Limited verification•Last verified: •Collection Degraded
CVE-2025-39948Unknown / EvaluatingCRITICAL (raw)CVSS 9.8CWE-401

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

Published: 04 Oct 2025•Last updated: 21 Oct 2026, 06:48 PM IST•Source identifier: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Dossier completeness: source-provided sections 2 / 3 · rule guidance available. Missing source facts count as incomplete.
Official source
CISA KEV catalog
Unknown
KEV status was not determined.
CVSS score
9.8CRITICAL (raw)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Metric source416baaa9-dc9f-4396-8d5f-8c081fb06d67
EPSS probability
0.4%0.004
Percentile34th
Weakness type
CWE-401
No further CWE recorded
Remediation
Patch status unknown
No fixed version or KB recorded

Why It Matters

Analysis dossier

Why It Matters

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.

SOC priority

High Severity / Review

Actively exploited (source statement)

Unknown

Publicly disclosed

Unknown

Risk basis: SOC ecosystem technology relevance; CRITICAL severity; Critical CVSS without confirmed KEV exploitation; Critical source severity without confirmed exploitation

Affected Products & Remediation

1 source-backed product
Affected products and versions (source)
  • linux linux kernel · >= 6.6.78 < 6.7; >= 6.12.14 < 6.12.49; >= 6.13.3 < 6.14; >= 6.14.1 < 6.16.9; 6.14; 6.17 · NVD CPE · Source
Recorded patch / KBNot provided by source

Vendor or catalog guidance (source)

Not provided by source

Known exploitation (source facts)

Only what a source states. Unknown means no source has said either way; it is not "not exploited".

CISA KEV
Unknown
Exploited (source statement)
Unknown
Publicly disclosed (source)
Unknown

Suggested hunting (rule-based inference)

SecOps Signal recommendation (rule-based inference). These steps are hunting hypotheses from the vulnerability class; they do not state or imply that exploitation occurred here or anywhere.

Matched network-unauthenticated (CVSS AV:N, CVSS PR:N, CVSS UI:N)

Exposure

  1. Identify devices reporting this CVE and note which expose the affected service to untrusted networks.Telemetry: DeviceTvmSoftwareVulnerabilities · A network-reachable, no-privilege vector makes internet-facing instances the first exposure question. · Rule network-unauthenticated

Exploitation evidence

  1. Review inbound connections to the affected service from unexpected sources since the advisory date.Telemetry: DeviceNetworkEvents · Hunting hypothesis from the CVSS vector; it does not show that exploitation occurred. · Rule network-unauthenticated

Response

  1. Confirm the source-stated update is installed and the CVE is no longer reported.Telemetry: DeviceTvmSoftwareVulnerabilities · A follow-up inventory check verifies remediation. · Rule network-unauthenticated

CISA KEV Record

CISA KEV status was not determined for this record.

Change History & Source Data

— No recorded material change

CNA / source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Record status · verification
UPDATED · NVD API
CPE
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:-:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc6:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.14:rc7:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*

Linked by the query's stored exact CVE association. Review required tables and validation status before use.

Detection Hunting Query
Target: DeviceTvmSoftwareVulnerabilities•Defender XDR
Detect endpoints exposed to CVE-2025-39948
Purpose: Exposure assessment (Category: Exposure Check)Why linked: Query metadata names CVE-2025-39948
DeviceTvmSoftwareVulnerabilities| where CveId == "CVE-2025-39948"| project DeviceId, DeviceName, OSPlatform, OSVersion, SoftwareVendor, SoftwareName, SoftwareVersion, CveId, VulnerabilitySeverityLevel, RecommendedSecurityUpdate, RecommendedSecurityUpdateId| sort by VulnerabilitySeverityLevel desc
Schema Checked · Not runtime validatedSource: SecOps Signal deterministic template · Limited verificationStatic screening: Passed structure and schema checks; tenant execution is not verified.

Looking up related community queries…

Loading related intelligence

Correlated briefings

SecOps Signal surfaces public advisory facts only. A missing value means the source has not published it, not that your environment is unaffected. No tenant inventory is connected.