{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-52935",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-52935"
  ],
  "published": "2026-06-24T07:13:41Z",
  "summary": "xfrm: espintcp: do not reuse an in-progress partial send",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: espintcp: do not reuse an in-progress partial send\n\nespintcp keeps a single in-flight transmit in ctx->partial.\nBefore building a new sk_msg, espintcp_sendmsg() first tries to flush\nthat state through espintcp_push_msgs().\n\nFor blocking callers, espintcp_push_msgs() may return success even when\nthe previous partial send is still pending. espintcp_sendmsg() would\nthen reinitialize emsg->skmsg and reuse ctx->partial while the old\ntransfer still owns that state.\n\nDo not rebuild the send message when ctx->partial is still in progress.\nIf espintcp_push_msgs() returns with emsg->len still set, fail the new\nsend instead of overwriting the live partial state.\n\nThis is a memory-safety fix: reusing the live partial-send state can\nleave a stale offset attached to a new sk_msg and lead to an out-of-\nbounds read in the send path.\n\ntcp_sendmsg_locked() already handles waiting for send buffer memory, so\nthe fix here is just to preserve espintcp's one-message-at-a-time\ntransmit state.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.176",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52935"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6564e9c7af7e1dc7bfe7f3093b728abe484d7630"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1777ceac4bea5e568a5ad44b7f9bb219c1db21b6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8c6c691bf062dc0753a139a4ab8cb92a70fcf8f3"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/aa82a078f70f7ff88ba7d1017134e79d1ac140f2"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ba21439302db9a82fe4edbed1e38a97271529421"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/37487d55bf3300e3d2c1368da5c2bd3e3834ea4f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c381039ade2e161ab08c0eda73c4f8b9a7115928"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T13:16:28Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable code is reached through local socket syscalls: an attacker creates/uses a TCP socket, sets `TCP_ULP` to `espintcp`, and calls send/sendmsg. It is not directly triggerable by unauthenticated network packets alone.\nAC:L - The attacker can create the needed partial-send condition by controlling the TCP peer or receiver behavior and filling the send buffer, then issuing another send. No race or condition outside attacker control is required.\nPR:L - Setting an already-registered TCP ULP does not require CAP_NET_ADMIN, and ordinary local users can create TCP sockets and call setsockopt/sendmsg. XFRM administration is privileged, but it is not required for this lowest-privilege path to `espintcp_sendmsg`.\nUI:N - Exploitation does not require any victim user action after the attacker has local code execution. The attacker directly drives the socket operations.\nS:U - The impact remains within the kernel and its managed resources on the same host. This is not a VM escape, IOMMU bypass, or cross-authority boundary violation.\nC:H - The stale partial-send offset can produce an out-of-bounds read in the TCP send path, potentially exposing kernel memory through transmitted data. Because the read is not strictly bounded to a small fixed disclosure, high confidentiality impact is appropriate.\nI:H - The corrupted espintcp/sk_msg state can build invalid bvec/socket-buffer references and disturb page or send-buffer accounting, which is a plausible kernel memory integrity primitive. Under the required higher-severity rule for uncertainty, this is scored as high integrity impact.\nA:H - The invalid scatterlist/bvec state can lead to kernel warnings, invalid page references, refcount/accounting corruption, or crashes in the send/cleanup path. A local attacker can repeat the trigger, so availability impact is high."
    }
  }
}