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)
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.
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.
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.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Apr 16, 2025, 14:12 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.