CVE-2025-40046 (GCVE-0-2025-40046)
Vulnerability from cvelistv5
Published
2025-10-28 11:48
Modified
2026-08-05 12:07
Severity ?
8.6 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix overshooting recv limit It's reported that sometimes a zcrx request can receive more than was requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow.
References
Impacted products
Vendor Product Version
Linux Linux Version: 6699ec9a23f85f1764183430209c741847c45f12
Version: 6699ec9a23f85f1764183430209c741847c45f12
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "io_uring/zcrx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8bcc9eaf1b19f1a7029cba19f6bd4122b40f6c4f",
              "status": "affected",
              "version": "6699ec9a23f85f1764183430209c741847c45f12",
              "versionType": "git"
            },
            {
              "lessThan": "09cfd3c52ea76f43b3cb15e570aeddf633d65e80",
              "status": "affected",
              "version": "6699ec9a23f85f1764183430209c741847c45f12",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "io_uring/zcrx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17.3",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/zcrx: fix overshooting recv limit\n\nIt\u0027s reported that sometimes a zcrx request can receive more than was\nrequested. It\u0027s caused by io_zcrx_recv_skb() adjusting desc-\u003ecount for\nall received buffers including frag lists, but then doing recursive\ncalls to process frag list skbs, which leads to desc-\u003ecount double\naccounting and underflow."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.6,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The vulnerable function is a TCP read actor operating on skbs received from the remote peer, and the triggering condition \u2014 a `frag_list`-chained skb built by `skb_gro_receive()` when frags exceed `MAX_SKB_FRAGS` \u2014 is determined entirely by the remote sender\u0027s traffic pattern, not by any local action. A client connected to a zcrx-enabled network server triggers it over the wire.\nAC:L - A peer sending a sustained burst of TCP segments reliably drives GRO into the frag-list merge path, and the double-accounting underflow follows deterministically once the remaining `desc-\u003ecount` budget is smaller than twice the frag-list bytes. No race and no attacker-uncontrollable state is involved.\nPR:N - The remote peer needs no credentials or privileges on the target \u2014 it only needs an established TCP connection to the zcrx-using service, which for a public-facing server is unauthenticated. The `capable(CAP_NET_ADMIN)` check in `io_register_zcrx_ifq()` is a property of the victim\u0027s own service setup, not a privilege the attacker must hold.\nUI:N - The overshoot occurs purely from processing inbound TCP data on an already-armed multishot `IORING_OP_RECV_ZC` request; no victim action beyond running the service is needed.\nS:U - The underflow, the over-read and the resulting request breakage are all confined to the kernel and the io_uring context that owns the socket and the registered zcrx area \u2014 no VM, IOMMU or sandbox boundary is crossed.\nC:L - The request is delivered socket data beyond the byte limit it explicitly requested, bypassing the read boundary that `IORING_OP_RECV_ZC`\u0027s `len` is supposed to enforce; in designs where that limit demarcates data handed off to a different consumer the extra bytes are disclosed to the wrong one. There is no out-of-bounds read or kernel-memory leak, so the exposure is bounded to the connection\u0027s own stream.\nI:L - The kernel writes more data into the application\u0027s registered zcrx area than requested and advances the socket\u0027s `copied_seq` past the limit, consuming stream state that should have stayed queued, and `zc-\u003elen` is corrupted by an unsigned wrap. All writes remain within correctly sized objects, so there is no arbitrary-write or control-flow primitive.\nA:H - With `zc-\u003elen` wrapped to ~4 G the multishot recvzc request\u0027s completion condition can never be satisfied, so the request hangs indefinitely while unboundedly draining the socket, exhausting the zcrx area\u0027s niovs and overflowing the completion queue until it fails with a spurious `-ENOMEM`/`-ENOSPC`. A remote peer can reproduce this on every connection, rendering the affected network service non-functional."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:07:19.429Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8bcc9eaf1b19f1a7029cba19f6bd4122b40f6c4f"
        },
        {
          "url": "https://git.kernel.org/stable/c/09cfd3c52ea76f43b3cb15e570aeddf633d65e80"
        }
      ],
      "title": "io_uring/zcrx: fix overshooting recv limit",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-40046",
    "datePublished": "2025-10-28T11:48:24.022Z",
    "dateReserved": "2025-04-16T07:20:57.154Z",
    "dateUpdated": "2026-08-05T12:07:19.429Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.