{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89482",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89482"
  ],
  "published": "2026-09-11T19:47:07Z",
  "summary": "nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone\n\nCommit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes\nprocessing\") established that blk_rq_payload_bytes() must not be read\nwithout first checking blk_rq_nr_phys_segments(), and recorded the\nresult in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side\nwas left as it was.\n\nThe two differ for REQ_OP_WRITE_ZEROES, which has no physical segments\nbut a non-zero blk_rq_bytes(), so setup leaves req->iter untouched\nwhile the receive gate lets a C2HData through and nvme_tcp_recv_data()\ncopies into whatever the previous command on that tag left there. The\ndriver-private area is zeroed only when the tag set is allocated.\n\nReproduced with a test target that leaves a residual iterator on a tag\nand then sends a C2HData for a WRITE_ZEROES command on the same tag:\n\nBUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330\nWrite of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103\n\nCPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy)\nHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nWorkqueue: nvme_tcp_wq nvme_tcp_io_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x53/0x70\n kasan_report+0xce/0x100\n ? _copy_to_iter+0x642/0x1330\n kasan_check_range+0x105/0x1b0\n __asan_memcpy+0x3c/0x60\n _copy_to_iter+0x642/0x1330\n ? __pfx_sock_has_perm+0x10/0x10\n ? worker_thread+0x45b/0xd10\n ? __pfx__copy_to_iter+0x10/0x10\n ? _raw_spin_lock_bh+0x83/0xe0\n ? __pfx__raw_spin_lock_bh+0x10/0x10\n __skb_datagram_iter+0xf3/0x820\n ? __pfx_simple_copy_to_iter+0x10/0x10\n ? __asan_memcpy+0x3c/0x60\n ? skb_copy_bits+0x58d/0x830\n skb_copy_datagram_iter+0x37/0x120\n nvme_tcp_recv_skb+0xa07/0x4320\n ? __pfx_nvme_tcp_recv_skb+0x10/0x10\n __tcp_read_sock+0x1ab/0x810\n ? __pfx_nvme_tcp_recv_skb+0x10/0x10\n ? __pfx_lock_sock_nested+0x10/0x10\n ? __pfx___tcp_read_sock+0x10/0x10\n nvme_tcp_try_recv+0x152/0x1e0\n ? __pfx_nvme_tcp_try_recv+0x10/0x10\n ? __pfx_mutex_unlock+0x10/0x10\n nvme_tcp_io_work+0x1e4/0x6c0\n ? __schedule+0x181a/0x49f0\n ? __pfx_nvme_tcp_io_work+0x10/0x10\n process_one_work+0x633/0x1030\n\nKeep the blk_rq_payload_bytes() test and add req->data_len to it. The\nold test is what rejects a C2HData naming a tag that is no longer in\nflight, because blk_update_request() zeroes rq->__data_len on\ncompletion; req->data_len and req->curr_bio are driver-private and\nsurvive completion, so they cannot stand in for it. Setup initialises\nthe iterator only when both req->curr_bio and req->data_len are set, so\nthe gate now tests the same two.",
  "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-89482"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/32ea8ce96b9bd797c59c351ce490ffd97adaa8c0"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/dd8906bb8f8d5bf1c9f861e1382c82b87bfe7cab"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/7ed0b61bbc145988be292c4d3ec580aebd8d2bcd"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b96e1ff75e5c0ad6e077ac002b1d30b0a2b49528"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b36161701cb366f416afdcf70771d432a7c74753"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6a01b58263108eaf9869bb6f82f07709240c6589"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/641ad3a30ba560f0a9a610376c568d7b75d2a2aa"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-14T12:06:03Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.8,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:N - The nvme-tcp host receive path parses C2HData PDUs from a remote NVMe/TCP target over a routable TCP connection (typically port 4420); a malicious or compromised target, or an on-path attacker injecting into the stream, triggers the bug from the network.\nAC:L - A malicious target can advertise WRITE_ZEROES, wait for tag reuse after a data command, and send C2HData for that in-flight WRITE_ZEROES; leftover iterator state is deterministic because driver-private fields are not cleared on reuse, so no race or memory-layout luck is required.\nPR:N - NVMe/TCP authentication (TLS, DH-HMAC-CHAP) is optional and off by default; the vulnerable copy runs on C2HData from the connected peer, which needs no credentials or privileges on the victim host.\nUI:N - Once the host is connected to the target as persistent storage, ordinary filesystem and block I/O generate WRITE_ZEROES commands; the attacker sends the crafted PDU without any further victim action.\nS:U - The stale-iterator write corrupts memory in the same host kernel security authority; this is not a VM, IOMMU, or sandbox boundary crossing.\nC:H - nvme_tcp_recv_data() writes attacker-controlled C2HData through a leftover iov_iter into pages from a previously completed command on the same tag, a use-after-free of those buffers that can be turned into an arbitrary read via heap reuse.\nI:H - The copy is a use-after-free / wild write of attacker-chosen contents and length into reused kernel or page-cache memory, which is exploitable for arbitrary write and control-flow hijacking.\nA:H - The same stale-iterator write was reproduced as a KASAN wild-memory-access in _copy_to_iter from nvme_tcp_io_work and can oops or panic the host kernel."
    }
  }
}