CVE-2025-22059 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix multiple wraparounds of sk->sk_rmem_alloc.
__udp_enqueue_schedule_skb() has the following condition:
if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;
sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE.
If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.
Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.
This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1].
For example, if we set a large value to udp_mem[1] and INT_MAX to
sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows:
# cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)
Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").
A complete fix would be to revert it and cap the right operand by INT_MAX:
rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop;
but we do not want to add the expensive atomic_add_return() back just for the corner case.
Casting rmem to unsigned int prevents multiple wraparounds, but we still allow a single wraparound.
# cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 > 12
# ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)
So, let's define rmem and rcvbuf as unsigned int and check skb->truesize only when rcvbuf is large enough to lower the overflow possibility.
Note that we still have a small chance to see overflow if multiple skbs to the same socket are processed on different core at the same time and each size does not exceed the limit but the total size does.
Note also that we must ignore skb->truesize for a small buffer as explained in commit 363dc73acacb ("udp: be less conservative with sock rmem accounting").
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability CVE-2025-22059 resides within the Linux kernel's UDP implementation, specifically in the handling of socket receive buffer memory allocation. This flaw stems from a lack of proper integer overflow protection during the accounting of received socket memory. The issue manifests in the `__udp_enqueue_schedule_skb()` function where the kernel checks if the current receive buffer allocation exceeds the socket's receive buffer limit. When a socket's receive buffer is set to INT_MAX, the condition that should prevent over-allocation becomes ineffective due to the signed integer nature of `sk->sk_rmem_alloc`. This oversight allows for multiple wraparounds of the signed integer, effectively bypassing memory limits and potentially leading to excessive memory consumption.
The technical root cause involves integer overflow in the memory accounting mechanism. When `sk->sk_rcvbuf` is set to INT_MAX, the boundary check that should prevent over-allocation becomes meaningless because `sk->sk_rmem_alloc` is also a signed integer. As packets arrive, their sizes are unconditionally added to `sk->sk_rmem_alloc`, which can overflow multiple times before reaching the actual limit. This behavior can be exploited to consume memory up to the limit defined by `net.core.udp_mem[1]`, enabling a form of memory exhaustion attack. The vulnerability was introduced when commit 6a1f12dd85a8 relaxed atomic operations on `sk->sk_rmem_alloc`, removing a previous boundary check that had protected against such overflows. The fix approach involves redefining variables as unsigned integers to prevent wraparounds while maintaining performance, though this solution still leaves a small window for overflow in multi-core scenarios where concurrent packet processing might collectively exceed limits.
The operational impact of this vulnerability is significant for systems running Linux kernels that process UDP traffic. An attacker could potentially consume excessive memory resources by sending specially crafted UDP packets to a socket with a large receive buffer configured. This could lead to denial of service conditions where legitimate processes are unable to allocate necessary memory, or in severe cases, cause system instability or crashes. The vulnerability is particularly concerning in environments handling high volumes of UDP traffic, such as network infrastructure devices, DNS servers, or any service that relies heavily on UDP communication. The memory consumption pattern shown in the `/proc/net/sockstat` output demonstrates how quickly memory can be consumed, with negative values appearing in the Recv-Q field indicating the integer overflow has occurred. This vulnerability aligns with CWE-190, Integer Overflow or Wraparound, and could be categorized under ATT&CK technique T1499.001, Network Denial of Service, as it enables an attacker to exhaust system resources through network-based attacks.
Mitigation strategies should focus on both immediate kernel updates and system-level configuration adjustments. The primary fix involves updating to a kernel version that includes the corrected memory accounting logic, which properly handles unsigned integer operations to prevent wraparounds. System administrators should also implement proper socket buffer size limits using `SO_RCVBUF` and `net.core.rmem_max` parameters to prevent accidental configuration of excessively large buffers. Monitoring for unusual memory consumption patterns in UDP sockets and implementing network-level rate limiting can provide additional protection against exploitation attempts. The fix addresses the specific conditions that lead to multiple wraparounds while maintaining performance characteristics, though the solution acknowledges that concurrent packet processing on multiple cores still presents a small risk of overflow. Organizations should also consider implementing network segmentation and access control measures to limit exposure to potential exploitation attempts targeting this vulnerability.