CVE-2025-39948

MEDIUMNVD 5.55.5
EchelonGraph scoreMEDIUM confidence

Score 5.5 from GitHub Security Advisory published 2025-10-04. NVD baseline CVSS 5.5; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, nvd
Trending — 3 sources updated this week
5.5EG
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 5.5Exploit: None knownExposed: 0

A fix is available — apply it.

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.

CVSS v3
5.5
EG Score
5.5(medium)
EG Risk
29(Track)
EG Risk 29/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity55% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
3%
KEV
Not listed

Published

October 4, 2025

Last Modified

March 25, 2026

Patch Availability(11)

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

All Vendor Advisories

(10)

Data Freshness Timeline

(refreshed 10× in last 7d / 45× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-26 14:54 UTCEPSS rescore
  2. 2026-07-25 14:17 UTCEPSS rescore
  3. 2026-07-25 14:17 UTCEPSS rescore
  4. 2026-07-24 14:17 UTCEPSS rescore
  5. 2026-07-23 18:11 UTCOSV refresh
  6. 2026-07-23 02:55 UTCEG score recompute
  7. 2026-07-22 14:07 UTCEPSS rescore
  8. 2026-07-22 14:07 UTCEPSS rescore
  9. 2026-07-21 15:24 UTCEPSS rescore
  10. 2026-07-20 17:07 UTCEPSS rescore
  11. 2026-07-19 14:30 UTCEPSS rescore
  12. 2026-07-19 14:30 UTCEPSS rescore
  13. 2026-07-19 02:28 UTCEPSS rescore
  14. 2026-07-19 02:28 UTCEPSS rescore
  15. 2026-07-18 10:04 UTCEPSS rescore
  16. 2026-07-18 10:04 UTCEPSS rescore
  17. 2026-07-16 17:02 UTCEPSS rescore
  18. 2026-07-15 16:57 UTCEPSS rescore
  19. 2026-07-15 16:57 UTCEPSS rescore
  20. 2026-07-15 01:59 UTCEPSS rescore
  21. 2026-07-15 01:59 UTCEPSS rescore
  22. 2026-07-13 22:29 UTCEPSS rescore
  23. 2026-07-13 22:29 UTCEPSS rescore
  24. 2026-07-13 06:12 UTCEPSS rescore
  25. 2026-07-12 05:46 UTCEPSS rescore
Show 64 more
  1. 2026-07-11 08:27 UTCEPSS rescore
  2. 2026-07-11 08:27 UTCEPSS rescore
  3. 2026-07-09 19:09 UTCEPSS rescore
  4. 2026-07-09 19:09 UTCEPSS rescore
  5. 2026-07-07 13:45 UTCEPSS rescore
  6. 2026-07-06 16:27 UTCEPSS rescore
  7. 2026-07-06 16:27 UTCEPSS rescore
  8. 2026-07-06 13:01 UTCOSV refresh
  9. 2026-07-05 02:30 UTCEPSS rescore
  10. 2026-07-04 06:30 UTCEPSS rescore
  11. 2026-07-01 15:06 UTCEPSS rescore
  12. 2026-07-01 15:06 UTCEPSS rescore
  13. 2026-06-30 23:22 UTCEPSS rescore
  14. 2026-06-30 23:22 UTCEPSS rescore
  15. 2026-06-29 14:06 UTCEPSS rescore
  16. 2026-06-29 14:06 UTCEPSS rescore
  17. 2026-06-28 14:07 UTCEPSS rescore
  18. 2026-06-28 14:07 UTCEPSS rescore
  19. 2026-06-28 04:55 UTCEPSS rescore
  20. 2026-06-28 04:55 UTCEPSS rescore
  21. 2026-06-27 03:08 UTCEPSS rescore
  22. 2026-06-27 03:08 UTCEPSS rescore
  23. 2026-06-25 13:49 UTCEPSS rescore
  24. 2026-06-25 13:49 UTCEPSS rescore
  25. 2026-06-24 14:04 UTCEPSS rescore
  26. 2026-06-24 14:04 UTCEPSS rescore
  27. 2026-06-23 21:32 UTCEPSS rescore
  28. 2026-06-23 21:32 UTCEPSS rescore
  29. 2026-06-22 14:25 UTCEPSS rescore
  30. 2026-06-22 14:25 UTCEPSS rescore
  31. 2026-06-21 14:56 UTCEPSS rescore
  32. 2026-06-21 14:56 UTCEPSS rescore
  33. 2026-06-19 19:25 UTCEPSS rescore
  34. 2026-06-19 19:25 UTCEPSS rescore
  35. 2026-06-18 01:05 UTCOSV refresh
  36. 2026-06-17 17:52 UTCEPSS rescore
  37. 2026-06-16 17:52 UTCEPSS rescore
  38. 2026-06-16 17:52 UTCEPSS rescore
  39. 2026-06-14 23:17 UTCEPSS rescore
  40. 2026-06-13 23:00 UTCEPSS rescore
  41. 2026-06-11 14:00 UTCEPSS rescore
  42. 2026-06-10 22:18 UTCEPSS rescore
  43. 2026-06-10 13:22 UTCEPSS rescore
  44. 2026-06-08 14:16 UTCEPSS rescore
  45. 2026-06-08 14:16 UTCEPSS rescore
  46. 2026-06-07 15:24 UTCEPSS rescore
  47. 2026-06-06 13:47 UTCEPSS rescore
  48. 2026-06-06 13:47 UTCEPSS rescore
  49. 2026-06-05 22:46 UTCEPSS rescore
  50. 2026-06-05 22:46 UTCEPSS rescore
  51. 2026-06-05 06:10 UTCEPSS rescore
  52. 2026-06-05 06:10 UTCEPSS rescore
  53. 2026-06-04 13:12 UTCEPSS rescore
  54. 2026-06-04 13:12 UTCEPSS rescore
  55. 2026-06-02 20:12 UTCEPSS rescore
  56. 2026-06-01 13:51 UTCEPSS rescore
  57. 2026-06-01 13:51 UTCEPSS rescore
  58. 2026-05-31 22:30 UTCEPSS rescore
  59. 2026-05-31 22:30 UTCEPSS rescore
  60. 2026-05-31 00:16 UTCEPSS rescore
  61. 2026-05-29 21:32 UTCEG score recompute
  62. 2026-05-29 21:32 UTCVendor advisory
  63. 2026-05-29 21:32 UTCGHSA enrichment
  64. 2026-05-29 13:44 UTCEPSS rescore

Frequently asked(5)

What is CVE-2025-39948?
CVE-2025-39948 is a medium vulnerability published on October 4, 2025. 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…
When was CVE-2025-39948 disclosed?
CVE-2025-39948 was first published in the National Vulnerability Database on October 4, 2025, with the most recent update on March 25, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2025-39948 actively exploited?
CVE-2025-39948 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 96.7% of all scored CVEs.
What is the CVSS score of CVE-2025-39948?
CVE-2025-39948 has a CVSS v3 base score of 5.5 (NVD).
How do I remediate CVE-2025-39948?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2025-39948, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2025-39948

Explore →

Is Your Infrastructure Affected by CVE-2025-39948?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.