{
  "affected": [
    {
      "ranges": [
        {
          "events": [
            {
              "introduced": "2195046bfd69e487d9a76dc47840f15c8412840c"
            },
            {
              "fixed": "d1297a9e2fd6ce08678b370d41bc980ca798f809"
            },
            {
              "fixed": "d33846c8dcc06b83b7acdeac1e8bfbb5c0c26cb2"
            }
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "type": "GIT"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Linux",
        "name": "Kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.15.0"
            },
            {
              "fixed": "7.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72380.json"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen/pvcalls: bound backend response req_id before indexing rsp[]\n\npvcalls_front_event_handler() takes req_id directly from the\nbackend-supplied ring response and uses it to index the fixed-size\nbedata-\u003ersp[] array for a memcpy() and a store, with no range check. A\nmalicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING\nand drive an out-of-bounds write past the bedata allocation.\n\nreq_id was also declared int while the wire field rsp-\u003ereq_id is u32, so\na range check on the signed value alone is insufficient: a backend\nreq_id of 0xffffffff becomes -1, passes a \u003e= PVCALLS_NR_RSP_PER_RING\ntest and indexes bedata-\u003ersp[-1]. Declare req_id as u32 so a single\nbound covers both ends.\n\nA backend that sends an out-of-range req_id has violated the wire\nprotocol, so rather than silently dropping the response, log once and\nstop trusting the backend: set bedata-\u003edisabled. The event handler then\nignores further responses, and the request paths that wait for a\nresponse return -EIO instead of blocking forever. This mirrors the\nfatal-error handling xen-netback uses (xenvif_fatal_tx_err()).\n\nThe pvcalls frontend currently trusts its backend, so this is not a\nclassic-Xen security issue, but it matters for hardening PV frontends\nagainst malicious backends (confidential and disaggregated deployments).",
  "id": "CVE-2026-72380",
  "modified": "2026-08-16T03:30:57.841525387Z",
  "published": "2026-08-15T05:56:12.866Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1297a9e2fd6ce08678b370d41bc980ca798f809"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d33846c8dcc06b83b7acdeac1e8bfbb5c0c26cb2"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72380.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72380"
    },
    {
      "type": "PACKAGE",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
    }
  ],
  "schema_version": "1.9.0",
  "summary": "xen/pvcalls: bound backend response req_id before indexing rsp[]"
}