{"id":"DEBIAN-CVE-2025-22059","details":"In the Linux kernel, the following vulnerability has been resolved:  udp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.  __udp_enqueue_schedule_skb() has the following condition:    if (atomic_read(&sk-\u003esk_rmem_alloc) \u003e sk-\u003esk_rcvbuf)           goto drop;  sk-\u003esk_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-\u003esk_rcvbuf, the condition is always false as sk-\u003esk_rmem_alloc is also signed int.  Then, the size of the incoming skb is added to sk-\u003esk_rmem_alloc unconditionally.  This results in integer overflow (possibly multiple times) on sk-\u003esk_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-\u003esk_rcvbuf and flood packets to the socket, we can see multiple overflows:    # cat /proc/net/sockstat | grep UDP:   UDP: inuse 3 mem 7956736  \u003c-- (7956736 \u003c\u003c 12) bytes \u003e INT_MAX * 15                                              ^- PAGE_SHIFT   # ss -uam   State  Recv-Q      ...   UNCONN -1757018048 ...    \u003c-- 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-\u003esk_rmem_alloc\").  A complete fix would be to revert it and cap the right operand by INT_MAX:    rmem = atomic_add_return(size, &sk-\u003esk_rmem_alloc);   if (rmem \u003e min(size + (unsigned int)sk-\u003esk_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  \u003c-- (INT_MAX + 1) \u003e\u003e 12    # ss -uam   State  Recv-Q      ...   UNCONN -2147482816 ...   \u003c-- 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-\u003etruesize 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-\u003etruesize for a small buffer as explained in commit 363dc73acacb (\"udp: be less conservative with sock rmem accounting\").","modified":"2026-08-27T23:05:13.677564246Z","published":"2025-04-16T15:15:59.380Z","upstream":["CVE-2025-22059"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-22059"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.25-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-22059.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.25-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-22059.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}