boxscore/security
CVE · referencelatest edition

Reference page — cumulative record through Wednesday, August 19, 2026 UTC. Reference pages update as the archive grows; only dated daily editions are immutable pages of record.

CVE-2025-22059MEDIUM
Linux Linux — udp: Fix multiple wraparounds of sk->sk_rmem_alloc.
  AV  AC  PR  UI  S  C  I  A   CVSS    EPSS   %ile   KEV
   L   L   L   N  U  N  N  H    5.5   .0044   36.8     —
AFFECTED
  Product  Versions                                    Fixed
  Linux    6a1f12dd85a8b24f871dfcf467378660af9c064d –  —
  Linux    6.10 –                                      6.12.23
TIMELINE
  Dec 29  Reserved by Linux
  Apr 16  Published (CNA: Linux)
  Jul 30  RESCORED — CVE-2025-22059 (Linux). CVSS 7.5 → 5.5 (NVD).
CWE-190 · CNA: Linux · CVSS v3.1 · 4 references · NVD status: Modified

Description

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 <-- (7956736 << 12) bytes > 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 <-- (INT_MAX + 1) >> 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").

Lifecycle

Complete event history — 3 events, chronological
DateEventDetail
December 29, 2024ReservedReserved by Linux
April 16, 2025PublishedPublished (CNA: Linux)
July 30, 2026RESCOREDRESCORED — CVE-2025-22059 (Linux). CVSS 7.5 → 5.5 (NVD).

Affected

Affected products and packages — 2 rows
VendorProduct / PackageEcosystemVersion introducedFixed
LinuxLinux6a1f12dd85a8b24f871dfcf467378660af9c064d
LinuxLinux6.106.12.23

Weaknesses

CWE-190

References (4)

Related

Authoritative record: CVE-2025-22059 at cve.org

Vendors: linux

Weaknesses: CWE-190

About this page

This is a reference page, not a dated page of record. It assembles the complete lifecycle of CVE-2025-22059 from the CVE Program record, NVD enrichment, the CISA KEV catalog, EPSS, and OSV advisories. The box score's numbers (CVSS, EPSS, KEV status) are current as of Wednesday, August 19, 2026 UTC and are re-derived as the archive grows; only dated daily editions are immutable pages of record. The authoritative source for this identifier is cve.org.