CVE-2025-22058

NVD 0.05.5
EchelonGraph scoreLOW confidence

Score 5.5 from GitHub Security Advisory published 2025-04-16.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: 0%CVSS: Exploit: NoneExposed: 0

A fix is available — apply it.

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

udp: Fix memory accounting leak.

Matt Dowling reported a weird UDP memory usage issue.

Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.

We can reproduce the issue with the script below [0]:

  • /proc/net/sockstat reports 0 pages

# cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0

  • Run the script till the report reaches 524,288

# python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT

  • Kill the socket and confirm the number never drops

# pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288

  • (necessary since v6.0) Trigger proto_memory_pcpu_drain()

# python3 test.py & sleep 1 && pkill python3

  • The number doubles

# cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577

The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().

When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.

The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.

Then, the released amount is calculated as follows:

1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().

When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().

At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).

Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.

This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.

To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.

Note that first_packet_length() also potentially has the same problem.

[0]: from socket import *

SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1

s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)

c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())

data = b'a' * 100

while True: c.send(data)

CVSS v3
EG Score
5.5(low)
EG Risk
25(Track)
EG Risk 25/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%
Automatability0% × 15%
Action: Routine — remediate on your standard cadence.
EPSS
10.3%
KEV
Not listed

Published

April 16, 2025

Last Modified

June 11, 2026

Patch Availability(30)

Vendor / EcosystemFixed in / PatchReleasedSource
ubuntulinux-tools-oracle-edge (6.8.0-1038.39~22.04.1) @ jammy2026-05-30ubuntu
ubuntulinux-tools-azure-nvidia-lts-24.04 (6.8.0-1029.32) @ noble2026-05-30ubuntu
ubuntulinux-tools-aws-edge (6.8.0-1041.43~22.04.1) @ jammy2026-05-30ubuntu
ubuntulinux-virtual-hwe-22.04-edge (6.8.0-86.87~22.04.1) @ jammy2026-05-30ubuntu
ubuntulinux-tools-raspi-6.8 (6.8.0-1041.45) @ noble2026-05-30ubuntu
ubuntulinux-tools-realtime-5.15 (5.15.0.1099.103) @ jammy2026-05-30ubuntu
ubuntulinux-virtual-hwe-20.04-edge (5.15.0.170.159) @ jammy2026-05-30ubuntu
ubuntulinux-tools-gcp-fips-5.15 (5.15.0.1100.90) @ jammy2026-05-30ubuntu
ubuntulinux-tools-nvidia-tegra-rt-5.15 (5.15.0.1052.52) @ jammy2026-05-30ubuntu
ubuntulinux-tools-aws-edge (5.15.0.1100.107~20.04.1) @ focal2026-05-30ubuntu
ubuntulinux-tools-oracle-edge (5.15.0.1097.103~20.04.1) @ focal2026-05-30ubuntu
ubuntulinux-xilinx-zynqmp-tools-5.15.0-1064 (5.15.0-1064.68) @ jammy2026-05-30ubuntu
ubuntulinux-tools-nvidia-tegra-igx-rt-5.15 (5.15.0.1041.43) @ jammy2026-05-30ubuntu
ubuntulinux-tools-nvidia-lowlatency-5.15 (5.15.0.1095.95) @ jammy2026-05-30ubuntu
ubuntulinux-tools-azure-lts-22.04 (5.15.0.1109.107) @ jammy2026-05-30ubuntu
ubuntulinux-tools-azure-fips-5.15 (5.15.0.1109.94) @ jammy2026-05-30ubuntu
ubuntulinux-tools-azure-edge (5.15.0.1110.119~20.04.1) @ focal2026-05-30ubuntu
redhatkernel-0:4.18.0-305.179.1.el8_42025-12-04redhat
redhatkernel-0:4.18.0-372.162.1.el8_62025-10-01redhat
redhatkernel-0:4.18.0-477.112.1.el8_82025-09-30redhat
redhatkernel-0:5.14.0-427.91.1.el9_42025-09-25redhat
redhatkernel-0:5.14.0-284.137.1.el9_22025-09-11redhat
redhatkernel-0:5.14.0-70.146.1.el9_02025-09-11redhat
redhatkernel-rt-0:5.14.0-284.137.1.rt14.422.el9_22025-09-10redhat
redhatkernel-0:4.18.0-193.168.1.el8_22025-09-10redhat
redhatkernel-rt-0:5.14.0-70.146.1.rt21.218.el9_02025-09-10redhat
redhatkernel-0:6.12.0-55.30.1.el10_02025-09-02redhat
redhatkernel-rt-0:4.18.0-553.71.1.rt7.412.el8_102025-08-25redhat
redhatkernel-0:4.18.0-553.71.1.el8_102025-08-25redhat
redhatkernel-0:5.14.0-570.37.1.el9_62025-08-25redhat

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.

Additional Vendor Advisories

(19)

Data Freshness Timeline

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

Frequently asked(4)

What is CVE-2025-22058?
CVE-2025-22058 is a publicly disclosed vulnerability published on April 16, 2025. In the Linux kernel, the following vulnerability has been resolved: udp: Fix memory accounting leak. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288…
When was CVE-2025-22058 disclosed?
CVE-2025-22058 was first published in the National Vulnerability Database on April 16, 2025, with the most recent update on June 11, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2025-22058 actively exploited?
CVE-2025-22058 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 10.3% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
How do I remediate CVE-2025-22058?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2025-22058, 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-22058

Explore →

Is Your Infrastructure Affected by CVE-2025-22058?

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