From nobody Fri Oct 2 12:22:02 2026 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4590931B82B for ; Sat, 1 Aug 2026 08:18:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785572323; cv=none; b=rhT6oIMP3vfmP4Q0twTg/ll6LAavnrubXehdelv69SvuZ+lmJlNjnqqX4uikCWJI84sNXEQbM4NEcIXKuzgotJnqJXKyEFN+9xWprFDY6we8kyvc4j5NsMxqogFBPmu51w1o6U6wU2ZfOE4V8Y2EI8IOSfn1+B1YA9P+QlbvDKA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785572323; c=relaxed/simple; bh=Jx5ngztfjkk1frVO0SfO5FKtgzZOYaWLyPYUFDjIz9k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ft7TljNmjL1oUF23umLPL2LFD0gkF4/aWN8jtZhD5eGTKo6HXRty0rxoVuWeNbFsI2BKhQjxKefSJGSRlmqCdEnqJTmmgtO32X8RI0CxcENzMtlys8+Y3OfcbxJ/sYdGoVoKNzEDLuoB3d7v4R7UC1HtJ3a7gEenFX1kH9/bHZ8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr; spf=none smtp.mailfrom=isslab.korea.ac.kr; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b=FQCLlntO; arc=none smtp.client-ip=209.85.210.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b="FQCLlntO" Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-84862b0d5aeso2269092b3a.2 for ; Sat, 01 Aug 2026 01:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1785572319; x=1786177119; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=f1eprebx+Ei9fy9zASKq2n4ZSux+Wxq0L1cBEFaU7cY=; b=FQCLlntOUi5JB7QtDvwZE6YgNuOvmR4BUj37IROxIB6rd1Zx+FHJNqO4N/scUUaCpH xGT0l6Z/dyneppRQ8CtNH898ueH3W2wjQgol58mbWUXY6ibTw+i/P0n9ooN/sgLlLzX/ UUz2CMT2ag4UhpXXIdyBTlnnrn1vBJUxZlVW67VQNRyNx0HLTji1t3io2hpxVzbDPZ0p GhelZGatBVc0zHaK1DEWt2PWErSfc95zN8irA4j1wfm/euF8MIOvv9BiTHZl6DIZ/dO5 OBVEL0iDmCduVtjfZEmwEedRoo4SjMf7/e6AovVEVKZbvogxZ0g1kqg60yCagfWFAH7b +WVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785572319; x=1786177119; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=f1eprebx+Ei9fy9zASKq2n4ZSux+Wxq0L1cBEFaU7cY=; b=mEhJgd8bOZrTIOBIcfATdIg8eHRyu/oR//WVNae7LY8Oj30hNVk7R0i/dBVkcHPxNi VEIiUtxQO2FFlHlIb/+pyjnvhgHBJiKt1AHmuE22spKJsofLCXbx+noHtk6Z2YAjFfAk F4eP32CYVSCINPNmdT4a+ebgtliWT1vK8wYh3W370F6hGNkAtS+/GfVRD3lRL6EV6urQ mV4MKYMyWvT2+Rn5pVsCR4tFNcpw59Dl2dyM0fzZ1yZZEM+kZI6O8rKsWyIzwghE+L6C 24I+4srvM7fBtIwVftCdZBhColJ8d7w6cXCNqIYKiYZhx+xHzSEmnRYHRLKZ+zLBNKtd FDUQ== X-Forwarded-Encrypted: i=1; AHgh+RrH5b2F4tMyz1Ac8PwR+1XEnVubIHkQdDqTMoZ64p6hG2Zt0pKwARwYHsqE0RTXhB1tdH3kxhcXH3Ds4ZI=@vger.kernel.org X-Gm-Message-State: AOJu0YwqTmfTTB2Tj3eF8v7cvEa6/yWY2OMpn5UQWpoJ0FerTM9uoB8U QJyrl+frcaBBEhgo3ucx06bl+MqgVHp4f3hdr5v8TeI4daJlDb2yU1rFj7hGJLdzUHc= X-Gm-Gg: AR+sD13NlxylLrFlSuwbJiVL5/azrSSe/VUbwHXsX6eYFk2Mxu8Y1AEtLClbPVv+JaT zbWzI3uxJ6k40VkUkOPyi4m/anA4O0A2ATwn8V5mdB+C5PuF94GJ4wQM/u8wcl1FI56o0rjQaBC wvvCydHjbJZeIZs/hx/4RzbvVZvbjpNOomEfjTPNHHrewwpxNeHgoQ9miLfXuG8p+6HDpZabAfc gumsibXRELwLRKZaCEytpAkRh42F0oR+uz+g3/JsE7hgNR3k+GIvt67XDPN2P/nA0QKK5Xj9bNn E8O/tcUhcORLXSGG258OA+el6U99mIW1QEjOy29bwVFl78U8RIROD8QRH7JhXrMTwl2lAtAmoNG ppBbQ+rVt+2x25obQWqntJmuVPslMCUJJqFpiR8aR8+THfiub/mxkGavm574LKS2sgf4xH0hDhQ YhwXtFCK91vqnfrXUI2V3xIobGriyV788cQJ/m5l6si2iYZeM5X47f1cbkA9MtgHauXZD+lWjcm NbQ5mnlFJ0= X-Received: by 2002:a05:6a00:9296:b0:847:82dc:452d with SMTP id d2e1a72fcca58-84ee47d8cf6mr2245492b3a.29.1785572319549; Sat, 01 Aug 2026 01:18:39 -0700 (PDT) Received: from localhost.localdomain ([2406:5900:1044:110c:c329:7b28:fe02:5dc8]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbe39ea9a40sm1433003a12.25.2026.08.01.01.18.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2026 01:18:39 -0700 (PDT) From: Yehyeong Lee To: linux-nvme@lists.infradead.org Cc: kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me, linux-kernel@vger.kernel.org, Yehyeong Lee , stable@vger.kernel.org Subject: [PATCH v3 1/2] nvme-tcp: reject a read that transferred too few bytes Date: Sat, 1 Aug 2026 17:18:17 +0900 Message-ID: <20260801081818.1884199-2-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260801081818.1884199-1-yhlee@isslab.korea.ac.kr> References: <20260801081818.1884199-1-yhlee@isslab.korea.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- v2 -> v3: the success test now uses req->status >> 1, the same expression nvme_try_complete_req() uses, so a CQE phase tag cannot evade it. drivers/nvme/host/tcp.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index ba5c7b3e2a7c..c4fe06d424d1 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -80,6 +80,7 @@ struct nvme_tcp_request { =20 struct bio *curr_bio; struct iov_iter iter; + u32 data_recvd; =20 /* send state */ size_t offset; @@ -612,6 +613,29 @@ static void nvme_tcp_error_recovery(struct nvme_ctrl *= ctrl) queue_work(nvme_reset_wq, &to_tcp_ctrl(ctrl)->err_work); } =20 +/* + * NVMe has no short read: a read that completes successfully must + * have transferred everything it asked for. + */ +static bool nvme_tcp_data_in_short(struct nvme_tcp_queue *queue, + struct request *rq) +{ + struct nvme_tcp_request *req =3D blk_mq_rq_to_pdu(rq); + + if (le16_to_cpu(req->status) >> 1) + return false; + if (req_op(rq) !=3D REQ_OP_READ || !req->data_len) + return false; + if (likely(req->data_recvd =3D=3D req->data_len)) + return false; + + dev_err(queue->ctrl->ctrl.device, + "queue %d tag %#x short data-in: got %u of %u\n", + nvme_tcp_queue_id(queue), rq->tag, + req->data_recvd, req->data_len); + return true; +} + static int nvme_tcp_process_nvme_cqe(struct nvme_tcp_queue *queue, struct nvme_completion *cqe) { @@ -631,6 +655,9 @@ static int nvme_tcp_process_nvme_cqe(struct nvme_tcp_qu= eue *queue, if (req->status =3D=3D cpu_to_le16(NVME_SC_SUCCESS)) req->status =3D cqe->status; =20 + if (unlikely(nvme_tcp_data_in_short(queue, rq))) + return -EPROTO; + if (!nvme_try_complete_req(rq, req->status, cqe->result)) nvme_complete_rq(rq); queue->nr_cqe++; @@ -953,6 +980,7 @@ static int nvme_tcp_recv_data(struct nvme_tcp_queue *qu= eue, struct sk_buff *skb, *len -=3D recv_len; *offset +=3D recv_len; queue->data_remaining -=3D recv_len; + req->data_recvd +=3D recv_len; } =20 if (!queue->data_remaining) { @@ -961,6 +989,8 @@ static int nvme_tcp_recv_data(struct nvme_tcp_queue *qu= eue, struct sk_buff *skb, queue->ddgst_remaining =3D NVME_TCP_DIGEST_LENGTH; } else { if (pdu->hdr.flags & NVME_TCP_F_DATA_SUCCESS) { + if (unlikely(nvme_tcp_data_in_short(queue, rq))) + return -EPROTO; nvme_tcp_end_request(rq, le16_to_cpu(req->status)); queue->nr_cqe++; @@ -1009,6 +1039,9 @@ static int nvme_tcp_recv_ddgst(struct nvme_tcp_queue = *queue, pdu->command_id); struct nvme_tcp_request *req =3D blk_mq_rq_to_pdu(rq); =20 + if (unlikely(nvme_tcp_data_in_short(queue, rq))) + return -EPROTO; + nvme_tcp_end_request(rq, le16_to_cpu(req->status)); queue->nr_cqe++; } @@ -2736,6 +2769,7 @@ static blk_status_t nvme_tcp_setup_cmd_pdu(struct nvm= e_ns *ns, req->status =3D cpu_to_le16(NVME_SC_SUCCESS); req->offset =3D 0; req->data_sent =3D 0; + req->data_recvd =3D 0; req->pdu_len =3D 0; req->pdu_sent =3D 0; req->h2cdata_left =3D 0; --=20 2.43.0 From nobody Fri Oct 2 12:22:02 2026 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92E0C32B13A for ; Sat, 1 Aug 2026 08:18:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785572327; cv=none; b=ct/+gEh1GN6TEg1rnkFJluJb8xl9NbFR9XZsLuNmZYq7g6OFe+/VaDRuriOG2rpE6oz+bqZ94ibvrHByQJsc4Gr50u7bAUIwo7O8gruC0JdVQJ2/YfR1TIoQBGigHURC6DidejREPVWj0oqg9KavHC7h7hcS7CeQj9dIZ86yEGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785572327; c=relaxed/simple; bh=b/eFGy+WGnEH6RkGlTWexGaLp97r9zOzyhM5fVs9sfk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JFXElBrcjdZ8823zhYYNRGlr1hRmUtYO9rh7+UCeZEpW3qL58nU6v5NId/7z/NOATlAg+aYkSXcgsw6nf1YKB8Ni1laAfySdlg+LUwmczXUvRSkxsQp9C2tiuUNmM66BEti208AdDkrX4eB1NBIf3/ieC8Bj0l1GrnigXbhRIc4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr; spf=none smtp.mailfrom=isslab.korea.ac.kr; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b=nykbev1f; arc=none smtp.client-ip=209.85.215.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=isslab.korea.ac.kr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i=@isslab-korea-ac-kr.20251104.gappssmtp.com header.b="nykbev1f" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-ca97d139d8dso985154a12.2 for ; Sat, 01 Aug 2026 01:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1785572324; x=1786177124; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1lwZlW3FZpQI3GTqv3UD9QOcWZj0C5mMeHQ3vQ2kJj0=; b=nykbev1fXB9HmQP87uaCOtdBOYObWHB/fn06JteiIAs2FMN5NclYYo7t1zRZx6nvv+ XRgkG2N5M+Rd7mhK+jNG5PrB05rmKEu+KU+0kt99ozpbtv8pbVf2g4nJtq3QZ2h60x7K 19xZdhRfOjLrznJSG0fgpYkIoD9o9ex6PzhSO0XK6ZxPWO7hiJgcGNbmXuWaIb6vz8VD IyCOKSK8KOgpqEbntrCrchBDAnGmsxaZgBNCHVevOqz/UFsMkLQ5VnGmoWy6GeNKtD4T 5zri0e/0am04Z0LkWZR7UhaBURQGDBKNYzPntcL5SSSyIwoyHEL/OgT64kvic03bxESG ipaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785572324; x=1786177124; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=1lwZlW3FZpQI3GTqv3UD9QOcWZj0C5mMeHQ3vQ2kJj0=; b=q36GkkuOU+zutemH/KzqGd0HLWqFOev2/9/niYdTxPGnGzHEYf3kDtOUFIeYlOp2Ki QNxTFecoZWF34kPaGESiHn2nNu9b72Ujw77kvByUHUDfUnZuCgLIQHp5Pku1BJKUZVtq 0xrhZEA4FjOsLCZ6HfPEnR2C4Q9tmpgNPk12tlXD+n+k7kRKq0iGGLkPa9li8yraK6ez Ct8mo1tbW5xy78JMoZ9gN6N2V/IY+hOIUJi81K3YvQ8IGagSXHsHRPhT4ciaMaWM8qzy 8lqCeFEY43nWaspW5TRtVDSsXCEWj2hJwyUQ/b0FrZdk6yhcwex4m209dTG0YH5qsMXz lXKg== X-Forwarded-Encrypted: i=1; AHgh+Rp+gwrtiRtDb6iZcebLUTz3Y90imEpeO6Td7dgjmHy4XO+cyX662N6taFfiCzS+9sibRhlZuNT+fTAXSFQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwMW6m/7pGtJDI3ISOjRosPd2Qr8NjOb+cec+OKYJvp/kvCpnLv vDMOkjQYr50Z+2liXMeUOSqdQIQcNc6K9ySDKT1jkKQ38imom+ovPoqMiLANghAba9E= X-Gm-Gg: AR+sD12nrqH8+Ewybt493qdUEcAybwn1bYfGmVouxqLqofZY8TEAsP9MfrYT/Dtu8A1 NqA8/cKq+A42ofNgR971APG4I8YtGh/i5f37fwP+rT5sPf93vKtJLAEPHJYGIS2Zi+Qc8hqMwVx VVuTokB00AGbF0GsLBdCk3M75/Zu9TYwXYB4RjzhQK/E9rlcmlVjlFYYYJCX9jobSrFzVQxsfh+ 7bmkLgjk5Owq1unIT81gNB1Nv3gvcrm5Mc6HEFAhP59bs8E+F8XPQwSVK+bDFdz7uim0QKKarVt 8FXRYa0Gr6pbj2Zb/QMcrN0lotjTeXwxWXyFiSGluGR/Ocpo/m5Varnyg4LCW1nMQND1jMB+NWF t9CqBs9itjLt/3IdqHvKPW15VtnUlMxY2wfPElsFaVmU3ekdmd14hqGjtGPz8KK4Ah9Q70Jvf+E J6KqPTVcO1pt46EQvlYVDTqqzlfdXv23KIfbh3bfZ1RHF4KiuH/+bfbfQ9nAtA5wq9TI0Ct4vVm uiOxnwn5R0= X-Received: by 2002:a05:6300:14d:b0:3c6:3c5b:f301 with SMTP id adf61e73a8af0-3c92a9519f2mr2907018637.68.1785572323922; Sat, 01 Aug 2026 01:18:43 -0700 (PDT) Received: from localhost.localdomain ([2406:5900:1044:110c:c329:7b28:fe02:5dc8]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbe39ea9a40sm1433003a12.25.2026.08.01.01.18.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2026 01:18:43 -0700 (PDT) From: Yehyeong Lee To: linux-nvme@lists.infradead.org Cc: kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me, linux-kernel@vger.kernel.org, Yehyeong Lee , stable@vger.kernel.org Subject: [PATCH v3 2/2] nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Date: Sat, 1 Aug 2026 17:18:18 +0900 Message-ID: <20260801081818.1884199-3-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260801081818.1884199-1-yhlee@isslab.korea.ac.kr> References: <20260801081818.1884199-1-yhlee@isslab.korea.ac.kr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5= 098b6bae76 #1 PREEMPT(lazy) Hardware 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 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two. Fixes: 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processi= ng") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- v2 -> v3: keep the blk_rq_payload_bytes() test and add to it; v2 replaced it and lost the rejection of a C2HData naming a tag that is no longer in fligh= t. drivers/nvme/host/tcp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index c4fe06d424d1..85a87ed6df93 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -668,6 +668,7 @@ static int nvme_tcp_process_nvme_cqe(struct nvme_tcp_qu= eue *queue, static int nvme_tcp_handle_c2h_data(struct nvme_tcp_queue *queue, struct nvme_tcp_data_pdu *pdu) { + struct nvme_tcp_request *req; struct request *rq; =20 rq =3D nvme_find_rq(nvme_tcp_tagset(queue), pdu->command_id); @@ -678,7 +679,8 @@ static int nvme_tcp_handle_c2h_data(struct nvme_tcp_que= ue *queue, return -ENOENT; } =20 - if (!blk_rq_payload_bytes(rq)) { + req =3D blk_mq_rq_to_pdu(rq); + if (!blk_rq_payload_bytes(rq) || !req->curr_bio || !req->data_len) { dev_err(queue->ctrl->ctrl.device, "queue %d tag %#x unexpected data\n", nvme_tcp_queue_id(queue), rq->tag); --=20 2.43.0