« Volver al listado

CVE-2025-22059

Estado: ModificadaMedia (5.5)—

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:

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].

Leer descripción completaMostrar menos

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:

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:

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.

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").

Detalles técnicos trazas, registros y código del informe original
  if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
          goto drop;

  # 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)

  rmem = atomic_add_return(size, &sk->sk_rmem_alloc);
  if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX))
          goto uncharge_drop;

  # 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)

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2025-22059",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-22059",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2025-10-01T17:41:49.675955Z"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.5,
          "attackVector": "NETWORK",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 3.9
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 5.5,
          "attackVector": "LOCAL",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 1.8
      },
      {
        "type": "Secondary",
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 5.5,
          "attackVector": "LOCAL",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "NONE"
        },
        "impactScore": 3.6,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
              "lessThan": "94d5ad7b41122be33ebc2a6830fe710cba1ecd75",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
              "lessThan": "1f529988efe9870db802cb79d01d8f473099b4d7",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
              "lessThan": "7571aadd20289e9ea10ebfed0986f39ed8b3c16b",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
              "lessThan": "5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "net/ipv4/udp.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.10",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.12.23",
              "versionType": "semver",
              "lessThanOrEqual": "6.12.*"
            },
            {
              "status": "unaffected",
              "version": "6.13.11",
              "versionType": "semver",
              "lessThanOrEqual": "6.13.*"
            },
            {
              "status": "unaffected",
              "version": "6.14.2",
              "versionType": "semver",
              "lessThanOrEqual": "6.14.*"
            },
            {
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "net/ipv4/udp.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2025-04-16T15:15:59.380",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/1f529988efe9870db802cb79d01d8f473099b4d7",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/7571aadd20289e9ea10ebfed0986f39ed8b3c16b",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/94d5ad7b41122be33ebc2a6830fe710cba1ecd75",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-190"
        }
      ]
    },
    {
      "type": "Secondary",
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "description": [
        {
          "lang": "en",
          "value": "CWE-190"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix multiple wraparounds of sk->sk_rmem_alloc.\n\n__udp_enqueue_schedule_skb() has the following condition:\n\n  if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)\n          goto drop;\n\nsk->sk_rcvbuf is initialised by net.core.rmem_default and later can\nbe configured by SO_RCVBUF, which is limited by net.core.rmem_max,\nor SO_RCVBUFFORCE.\n\nIf we set INT_MAX to sk->sk_rcvbuf, the condition is always false\nas sk->sk_rmem_alloc is also signed int.\n\nThen, the size of the incoming skb is added to sk->sk_rmem_alloc\nunconditionally.\n\nThis results in integer overflow (possibly multiple times) on\nsk->sk_rmem_alloc and allows a single socket to have skb up to\nnet.core.udp_mem[1].\n\nFor example, if we set a large value to udp_mem[1] and INT_MAX to\nsk->sk_rcvbuf and flood packets to the socket, we can see multiple\noverflows:\n\n  # cat /proc/net/sockstat | grep UDP:\n  UDP: inuse 3 mem 7956736  <-- (7956736 << 12) bytes > INT_MAX * 15\n                                             ^- PAGE_SHIFT\n  # ss -uam\n  State  Recv-Q      ...\n  UNCONN -1757018048 ...    <-- flipping the sign repeatedly\n         skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)\n\nPreviously, we had a boundary check for INT_MAX, which was removed by\ncommit 6a1f12dd85a8 (\"udp: relax atomic operation on sk->sk_rmem_alloc\").\n\nA complete fix would be to revert it and cap the right operand by\nINT_MAX:\n\n  rmem = atomic_add_return(size, &sk->sk_rmem_alloc);\n  if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX))\n          goto uncharge_drop;\n\nbut we do not want to add the expensive atomic_add_return() back just\nfor the corner case.\n\nCasting rmem to unsigned int prevents multiple wraparounds, but we still\nallow a single wraparound.\n\n  # cat /proc/net/sockstat | grep UDP:\n  UDP: inuse 3 mem 524288  <-- (INT_MAX + 1) >> 12\n\n  # ss -uam\n  State  Recv-Q      ...\n  UNCONN -2147482816 ...   <-- INT_MAX + 831 bytes\n         skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)\n\nSo, let's define rmem and rcvbuf as unsigned int and check skb->truesize\nonly when rcvbuf is large enough to lower the overflow possibility.\n\nNote that we still have a small chance to see overflow if multiple skbs\nto the same socket are processed on different core at the same time and\neach size does not exceed the limit but the total size does.\n\nNote also that we must ignore skb->truesize for a small buffer as\nexplained in commit 363dc73acacb (\"udp: be less conservative with\nsock rmem accounting\")."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrigen múltiples encapsulamientos de sk-&gt;sk_rmem_alloc. __udp_enqueue_schedule_skb() tiene la siguiente condición: if (atomic_read(&amp;sk-&gt;sk_rmem_alloc) &gt; sk-&gt;sk_rcvbuf) goto drop; sk-&gt;sk_rcvbuf se inicializa con net.core.rmem_default y posteriormente se puede configurar con SO_RCVBUF, que está limitado por net.core.rmem_max o SO_RCVBUFFORCE. Si se establece INT_MAX en sk-&gt;sk_rcvbuf, la condición siempre es falsa, ya que sk-&gt;sk_rmem_alloc también es un entero con signo. En ese caso, el tamaño del skb entrante se añade a sk-&gt;sk_rmem_alloc incondicionalmente. Esto provoca un desbordamiento de enteros (posiblemente varias veces) en sk-&gt;sk_rmem_alloc y permite que un único socket tenga skb hasta net.core.udp_mem[1]. Por ejemplo, si establecemos un valor grande en udp_mem[1] e INT_MAX en sk-&gt;sk_rcvbuf e inundamos el socket con paquetes, podemos ver múltiples desbordamientos: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 &lt;-- (7956736 &lt;&lt; 12) bytes &gt; INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... &lt;-- invirtiendo el signo repetidamente skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Anteriormente, teníamos una verificación de límite para INT_MAX, que se eliminó mediante el commit 6a1f12dd85a8 (\"udp: relajar la operación atómica en sk-&gt;sk_rmem_alloc\"). Una solución completa sería revertirlo y limitar el operando derecho con INT_MAX: rmem = atomic_add_return(size, &amp;sk-&gt;sk_rmem_alloc); if (rmem &gt; min(size + (unsigned int)sk-&gt;sk_rcvbuf, INT_MAX)) goto uncharge_drop; pero no queremos añadir el costoso atomic_add_return() solo para casos excepcionales. Convertir rmem a unsigned int evita múltiples encapsulamientos, pero aún permite un único encapsulamiento. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 &lt;-- (INT_MAX + 1) &gt;&gt; 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... &lt;-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) Por lo tanto, definamos rmem y rcvbuf como unsigned int y verifiquemos skb-&gt;truesize solo cuando rcvbuf sea lo suficientemente grande como para reducir la posibilidad de desbordamiento. Tenga en cuenta que aún existe una pequeña probabilidad de ver un desbordamiento si se procesan múltiples skbs al mismo socket en diferentes núcleos al mismo tiempo y cada tamaño no excede el límite, pero el tamaño total sí. Tenga en cuenta también que debemos ignorar skb-&gt;truesize para un buffer pequeño como se explica en el commit 363dc73acacb (\"udp: sea menos conservador con la contabilidad de sock rmem\")."
    }
  ],
  "lastModified": "2026-07-30T06:22:09.673",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "CD08468B-6C62-4470-90F6-7F16F10CF3B4",
              "versionEndExcluding": "6.12.23",
              "versionStartIncluding": "6.10"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "E7E864B0-8C00-4679-BA55-659B4C9C3AD3",
              "versionEndExcluding": "6.13.11",
              "versionStartIncluding": "6.13"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "FADAE5D8-4808-442C-B218-77B2CE8780A0",
              "versionEndExcluding": "6.14.2",
              "versionStartIncluding": "6.14"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}