{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-89480", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-89480" ], "published": "2026-09-11T19:47:07Z", "summary": "nvme-tcp: reject a read that transferred too few bytes", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: reject a read that transferred too few bytes\n\nnvme_tcp_recv_data() completes a request once the current C2HData PDU\nhas been consumed. Nothing compares the total bytes received against\nthe length the command asked for: struct nvme_tcp_request has no\nreceive-side counter, queue->data_remaining is per queue, and\nblk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally\nwith no residual concept anywhere above.\n\nA controller can therefore answer a 4096-byte read with 512 bytes and\nhave it reported as a complete read; user space then gets 4096 bytes of\nwhich 3584 are whatever was already in the page. I reproduced that with\na test target.\n\nCount the bytes received and refuse to complete a successful read whose\ncount does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in\nnvme_tcp_process_nvme_cqe(). The success test shifts req->status right\nby one, because the driver keeps the wire value there and shifts it on\ncompletion, so the check must see what the completion path will see.\nOnly REQ_OP_READ is checked, because there the length comes from the\nsectors the request covers; a passthrough command is built by its\nsubmitter, which picks both command and buffer, so the kernel has\nnothing to compare against.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N" } ], "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-89480" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a5c1bb0fb1bab2f24a081339c145870697f6d220" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/aa107e3a68f4af177d60f2d87679e7f67179a36c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fca3ebb63e5c82561cd9934365dcc0d068008006" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/99066cf9bba175f610ceb61a35f6fc9fbc33ff65" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8a02ad98798fd01f51f648c1fdd8f3c9d07195d3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/832a685efeb5d925ee7d30011d2dbe45f81447a3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7fa3f73f6c8ddc5f0425b50fb2a626a782ef7d12" } ], "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": 7.5, "cvss_v3_severity": "High", "scenario": "AV:N - C2HData is parsed on the nvme-tcp host socket path (nvme_tcp_data_ready -> nvme_tcp_try_recv -> nvme_tcp_recv_skb -> nvme_tcp_recv_data) over routable TCP (typically 4420). A malicious or compromised NVMe-oF target, or an on-path injector into the default-unencrypted stream, triggers it from the network.\nAC:L - nvme_tcp_handle_c2h_data() sets queue->data_remaining from the attacker-controlled PDU data_length with no comparison to req->data_len. A short or zero-length C2HData with NVME_TCP_F_DATA_SUCCESS, or a short C2HData plus a success CQE, completes the read every time; no race or layout dependence.\nPR:N - The attacker is the NVMe-oF peer and needs no host account or capability. NVMe/TCP is unauthenticated by default (DH-HMAC-CHAP and TLS are optional), so a malicious, compromised, or spoofed target can short any in-flight read once the fabrics connection exists.\nUI:N - NVMe-oF controllers are persistent boot/autoconnect configuration and are re-established by nvme_tcp_error_recovery(). Namespace scan, partition probe, udev, and mounted-filesystem readahead issue REQ_OP_READ from kernel work without further victim action at attack time.\nS:U - Leftover host page-cache and buddy-page contents are exposed to local readers of the same kernel's NVMe device. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - blk_mq_end_request() completes the full blk_rq_bytes, so userspace and page cache see leftover destination-page bytes as valid data. Those pages are not zeroed; sibling CVE-2026-89481 showed they hold stale kernel data including struct page pointers. Leak size is attacker-chosen up to the whole I/O, including a 0-length SUCCESS PDU.\nI:N - The bug under-fills the bio and reports success; it does not write out of bounds, free an object, or give a kernel write/hijack primitive. Bytes the target does send are data a storage controller already controls, and leftover bytes are prior page contents rather than attacker-chosen writes.\nA:N - The vulnerable path completes the request as success with no oops, panic, hang, deadlock, or leak. Availability of the host kernel is unaffected; error recovery (-EPROTO) exists only after the fix." } } }