LiveActive security incident?Get immediate response
CVE Record

CVE-2025-22058: udp: Fix memory accounting leak.

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]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. 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 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. 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)

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2025-22058 is a Linux kernel UDP memory accounting bug. A crafted or unusual UDP socket buffer condition can make the kernel believe UDP has consumed far more memory than it has. That stale accounting can cause UDP packet drops. The source bundle does not provide CVSS, active exploitation evidence, or a complete vendor-by-vendor impact matrix.

Executive priority

Patch during the normal urgent kernel maintenance cycle, with faster handling for UDP-heavy or packet-loss-sensitive systems. There is no supplied evidence of active exploitation, but the business impact can include service degradation and hard-to-diagnose packet loss.

Technical view

The bug is an integer overflow in UDP receive memory release accounting. When a socket is closed, a large receive queue total can wrap when passed into udp_rmem_release(), incorrectly increasing udp_memory_allocated. Later UDP receive activity can make the apparent usage grow, causing allocation failure and packet drops once thresholds are exceeded.

Likely exposure

Exposure is most relevant to Linux systems running affected kernels with workloads that allow large UDP receive buffers or heavy UDP socket activity. The source names Linux kernel affected entries and stable fix commits, but does not state remote exploitability, authentication requirements, or required privileges.

Exploitation context

The CVE record includes a reproducer and explains the triggering condition, but KEV is false and the supplied sources do not report active exploitation. Treat this as a reliability and denial-of-service risk until vendor scoring and advisories clarify practical exploitability.

Researcher notes

Key uncertainty is exploitability outside controlled reproduction. The record ties the issue to SO_RCVBUF behavior and udp_rmem_release() signedness, but does not state privilege requirements. Focus validation on kernel lineage, backported fixes, persistent UDP sockstat anomalies, and distribution advisories.

Mitigation direction

  • Update to vendor kernel builds containing the referenced stable fixes.
  • For Debian LTS systems, review and apply the May 2025 Debian LTS kernel advisory.
  • Prioritize hosts running UDP-heavy services or workloads with custom socket buffer settings.
  • Monitor vendor advisories for CVSS, backport status, and distribution-specific package names.
  • Avoid inventing local mitigations; use vendor guidance where patching is delayed.

Validation and detection

  • Inventory Linux kernel versions across servers, appliances, containers hosts, and UDP-facing infrastructure.
  • Compare installed kernels against distribution advisories and the referenced stable fix commits.
  • Check /proc/net/sockstat for abnormal persistent UDP memory accounting where operationally appropriate.
  • Review UDP packet-drop telemetry for unexplained intermittent drops on suspected hosts.
  • Confirm patched kernels after reboot, not only package installation.
Prepared
Confidence
medium
Sources
12

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-22058 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
Unknown
CVSS
Not scored
Known Exploited
No
Published
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.

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

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.

ADP provider summaries

CVECVE Program Container
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxf970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb, f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17ebunaffected
LinuxLinux4.10, 0, 5.4.301, 5.10.246, 5.15.195, 6.1.134, 6.6.87, 6.12.23, 6.13.11, 6.14.2, 6.15affected
Weakness

CWE details

No CWE listed

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