CVE-2025-22059: udp: Fix multiple wraparounds of sk->sk_rmem_alloc.

In the Linux kernel, the following vulnerability has been resolved:

udp: Fix multiple wraparounds of sk->skrmemalloc.

udpenqueuescheduleskb() has the following condition:

if (atomicread(&sk->skrmemalloc) > sk->skrcvbuf) goto drop;

sk->skrcvbuf is initialised by net.core.rmemdefault and later can be configured by SORCVBUF, which is limited by net.core.rmemmax, or SORCVBUFFORCE.

If we set INTMAX to sk->skrcvbuf, the condition is always false as sk->skrmemalloc is also signed int.

Then, the size of the incoming skb is added to sk->skrmemalloc unconditionally.

This results in integer overflow (possibly multiple times) on sk->skrmemalloc and allows a single socket to have skb up to net.core.udpmem[1].

For example, if we set a large value to udpmem[1] and INTMAX to sk->skrcvbuf and flood packets to the socket, we can see multiple overflows:

# cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INTMAX 15 ^- PAGESHIFT # 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 INTMAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->skrmemalloc").

A complete fix would be to revert it and cap the right operand by INTMAX:

rmem = atomicaddreturn(size, &sk->skrmemalloc); if (rmem > min(size + (unsigned int)sk->skrcvbuf, INTMAX)) goto unchargedrop;

but we do not want to add the expensive atomicaddreturn() 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 <-- (INTMAX + 1) >> 12

# ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INTMAX + 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").