{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89969",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89969"
  ],
  "published": "2026-09-16T10:32:03Z",
  "summary": "nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix out-of-bounds write when receiving an over-long PDU\n\nnvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte\nqueue->pdu union, then computes the remaining payload length as\n\n\tqueue->left = hdr->hlen - queue->offset + hdgst;\n\nand reads that many more bytes into &queue->pdu + queue->offset, without\never bounding the result against sizeof(queue->pdu).\n\nA struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the\nunion. Once a header digest has been negotiated (hdgst = 4), a second\nICReq passes the hlen == nvmet_tcp_pdu_size() check but yields\nqueue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the\n128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and\nqueue->data_digest. Those bytes are attacker-controlled (an ICReq\ncarries no digest), and the duplicate ICReq is only rejected later,\nafter the overflow. A remote unauthenticated host can thus corrupt\nkernel memory adjacent to the receive buffer.\n\nReject any PDU whose declared length would read past the end of\nqueue->pdu before the second recv.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/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.188",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89969"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a3f0bcfbaf3312a5754d1ce020a07d394669eb25"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/4f84d42c53c49557fb1ef285c683b0a81b576c74"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/58dc6035b79c4c73c0cbf9ec9f68a7f117b2b3e6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/cf5f39d2b58f97e0cd1829c4a6aeef17f1607cca"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3a385e0c39efbe34db8edd95900c123113ae3450"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/dbc4acbdb3ca8c81441368ad7409b8f77d4de8f6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d95d342bc0ea82dc79e6362b2f1f997431750e4c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/14cc5a7e77731497d5bea70f3bb05df7eda982e4"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-16T14:40:32Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.8,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:N - The flaw is in nvmet-tcp, an in-kernel NVMe-over-TCP target that accepts remote TCP connections; nvmet_tcp_try_recv_pdu() copies attacker-controlled PDU bytes from the socket, so the overflow is reachable from any network peer that can connect to an exposed NVMe-oF TCP port (typical cloud/storage-server deployment).\nAC:L - The attacker enables header digest in the first ICReq (the target copies the initiator's digest flags with no extra configuration), then sends a second 128-byte ICReq; queue->left becomes 124 and four attacker-controlled bytes are written past queue->pdu with no race or condition outside attacker control.\nPR:N - The overflow fires on a duplicate ICReq after TCP accept and digest negotiation, before NVMe Connect, host NQN allow-list, or DH-HMAC-CHAP in-band authentication; no Linux credentials or capabilities on the target are required.\nUI:N - Exploitation requires only attacker-sent NVMe/TCP PDUs to an already listening target port; no victim user action such as mounting a filesystem or opening a device is needed.\nS:U - The out-of-bounds write corrupts fields of the host's nvmet_tcp_queue in kernel memory and does not cross a VM, hypervisor, container, or IOMMU security boundary.\nC:H - Attacker-controlled 4-byte overflow into kernel memory adjacent to queue->pdu is memory corruption that, per kernel guidance, can be leveraged for information disclosure (including by clearing hdr_digest so later verify_hdgst is skipped and by controlling the persisted digest-flag bytes).\nI:H - This is an attacker-controlled out-of-bounds write past the 128-byte queue->pdu union into adjacent kernel fields (hdr_digest and data_digest); per kernel guidance an OOB write is High integrity impact and can disable PDU digest verification before the duplicate ICReq is rejected.\nA:H - After the overflow, nvmet_tcp_done_recv_pdu() returns -EPROTO and nvmet_tcp_socket_error() calls nvmet_ctrl_fatal_error() once a controller exists (e.g. after unauthenticated Discovery Connect), taking down the NVMe target; the kernel memory corruption can also oops, and the trigger is remotely repeatable."
    }
  }
}