cbcvebase.
CVE-2025-22059
published 2025-04-16

CVE-2025-22059: 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…

PriorityP423medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.44%
36.2th percentile
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 ... 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 ... 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").

Affected

12 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.25-1 (forky)linux 6.12.25-1 (forky)
linuxlinux
linuxlinux>= 6a1f12dd85a8b24f871dfcf467378660af9c064d < 94d5ad7b41122be33ebc2a6830fe710cba1ecd7594d5ad7b41122be33ebc2a6830fe710cba1ecd75
linuxlinux>= 6a1f12dd85a8b24f871dfcf467378660af9c064d < 1f529988efe9870db802cb79d01d8f473099b4d71f529988efe9870db802cb79d01d8f473099b4d7
linuxlinux>= 6a1f12dd85a8b24f871dfcf467378660af9c064d < 7571aadd20289e9ea10ebfed0986f39ed8b3c16b7571aadd20289e9ea10ebfed0986f39ed8b3c16b
linuxlinux>= 6a1f12dd85a8b24f871dfcf467378660af9c064d < 5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e35a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.12.25-16.12.25-1
linuxlinux_kernel>= 0 < 6.14.0-22.226.14.0-22.22
linuxlinux_kernel>= 6.10 < 6.12.236.12.23
linuxlinux_kernel>= 6.13 < 6.13.116.13.11
linuxlinux_kernel>= 6.14 < 6.14.26.14.2

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.9MEDIUM
vendor_ubuntu5.9MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.