From nobody Fri Oct 2 11:43:13 2026 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (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 8FAB03655C7 for ; Sat, 1 Aug 2026 06:02:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785564167; cv=none; b=cmqphTk0Nl6J/fOWcKNwCbrhvKvLjRRihGoA3vQLEJEFWhdVRfWQEA/PvUuK6/cZXShHjdZRjf8Zu+GoXcAk99GTCKOA5UC37zktYzVUEm7GorCPbSUtiVTp7hXqtylvWSBonvz4Jzr7huRrrL8QJiVsaMsxZWrUCG2gKWNKN0E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785564167; c=relaxed/simple; bh=kboCeEk3P8qTdtkY6pM4vU9Wh3/RBMOT82Ve6CeNWkI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G+NVDqxcsPpFwFHx3bq+TIxcJbD2kFqEKn1crjwRaVT9l+4MY2cGLu3jKBmB2wugrXQapfmczczxZYReG4rdaM0taQV92iY9xC+xKqUJtCwZ9p/ealJSFte44hpN/UDtIeOZAIqZ10s0S1TNPeDE7zb1NlK6uPBihI78/RKqnLs= 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=kMOUD7h5; arc=none smtp.client-ip=209.85.216.53 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="kMOUD7h5" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-38e071ed6aeso1434099a91.0 for ; Fri, 31 Jul 2026 23:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1785564165; x=1786168965; 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=Ar0TU0A76j4CC+o54wdVQpftKVR0bXPf2ahLSopc8SM=; b=kMOUD7h5z719d6djKqkcxZn0C88exEwD1EQHwjGUNtX6asAv0M40V1InCj0s1yqLnZ t71g5B+Dj3c1mLodU6eMNvjY7SDv2N2wgWMtFVIv8ZbxnOZ/dtjIb+4Ttyz159b2XFKo fW6ol8k86io1QXJtXlq0yHaDL5QMSl8xkX5iLiH6cdI6hDummlQ/CILjDNtimFeG+br+ wL890lm2ouDq9zkeSyvgRzfSBtsMhSWbA4gyuC03plqzG+l4iL2i2dsm+EX6/Q9+lL0q ScBisE56BX4N7AkhAx0jPhBp4UiAVty3Jv97zOP7kupuYh7curSk7GVPydTyIvnTNUpR nzLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785564165; x=1786168965; 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=Ar0TU0A76j4CC+o54wdVQpftKVR0bXPf2ahLSopc8SM=; b=sKK+edFKpxNRBjpXPpSdZCD3bvM/qgRzWLhHPAgY+XK8Cip5/qYZ1xFqJ/iRpCVIZI 6o3PEDLIZtwSBEd38/vXRVT9w7ZJC1/JbSHgFOfnzYiNITYr0CMpG7ZlaIR2Y1/RPhsv ULeJT+702c5+NjoF6VwCFmCISSB9dH+AeODl87ZShKMr/SFhDI2l5nmkIiubSFwd2QdW GB6l+2rz61+QYYAjoSTtax43tIb8eEbk8dmBZhbsqZa3/fkyngucKC+A35PF2el6O8hw D79hEhhOA34yNxm72eKfkvPe74mjuZJncqar3EpWmHtVBaGgbaweh41uoiZWkLiICUdB U59Q== X-Forwarded-Encrypted: i=1; AHgh+RpjNCDq9dz2UAkM6o88gZzwZeUMWTLQ5l4YYOgFPJin8s4UXOSOMg33r8luIqLDfA5MYowg5ImelnO81mI=@vger.kernel.org X-Gm-Message-State: AOJu0YxghW/pPHoVIwF80y/HE/0NcoLKd9dxcwiU8jHJlaCQPOE7TBd2 lkHgR2ozYlaEakX1CheCCmD3u+Otq5MIRQ+Z0I9bZjW8OP8ptOiDe6n+qwrhPdelqs0= X-Gm-Gg: AR+sD13fKfFCrO3xHZ8OYWGqtNUYKrttsoJ8D6oglURsbNt2g2ehTHxRCikUGaYHOdG SWSc0rjpCFaA+lNqdffEEf+4U7HPBd4jTWuM7v54PypNt3VByPSDL+PhjnTiRG/ARiv6qtHYjZ5 YpO4yL+4F2VnvvVkAuR36CnrRubnzF0U7vcr90EY8YnPyQitso4qd0NnutbSHymCyz8Dq7KLSCv d/urqlSyBHTk9ee66R7nv5a8v9lgkYe+T5/UAILUuGq5q+eQC0oQ+wAg4pRc7Daxd+nWYerqPJk 1Qqncz5a4dNT0ey2+AFKlucgQwL1FNfvwM+FtcndLsNfF/JH/ZyoQCOpEw6y8SJg9sfmzgRQfTu g+MFWnGoqsWzV5UklNsXGB+yfdo4MRcyw8y6bXwI6DAiQIZEtHjitkPJu1NgM2ETGIlUAV1lkny 8KFlcz0PhYoQWmKcy+veJiUbGVDkd4+RpMu7W3JkV5kKdAJij8kVokh6XiaLU/KS0h0pT1eZmY0 7rkmULE6w8= X-Received: by 2002:a17:90b:1d52:b0:381:3b5d:30f4 with SMTP id 98e67ed59e1d1-38fbc40e3a0mr2124348a91.1.1785564164843; Fri, 31 Jul 2026 23:02:44 -0700 (PDT) Received: from localhost.localdomain ([2406:5900:1044:110c:c329:7b28:fe02:5dc8]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38fb2bae2efsm1598856a91.11.2026.07.31.23.02.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 23:02:44 -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 v2 1/2] nvme-tcp: reject a read that transferred too few bytes Date: Sat, 1 Aug 2026 15:02:00 +0900 Message-ID: <20260801060201.1879499-2-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260801060201.1879499-1-yhlee@isslab.korea.ac.kr> References: <20260801060201.1879499-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, and queue->data_remaining is per queue, not per command. The layers above do not catch it either, since blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally and nothing here has a residual concept. 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(). 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 the command and the 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 --- v1 -> v2: an automated review pointed out that the check also applied to passthrough commands, where the kernel does not know the command's real transfer length; restricted to REQ_OP_READ. Patch 2/2 is unchanged. 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..4b72f555495d 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 (req->status !=3D cpu_to_le16(NVME_SC_SUCCESS)) + 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 11:43:13 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 D541026B971 for ; Sat, 1 Aug 2026 06:02:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785564171; cv=none; b=faGO/xNnZmnbjAfp7GVXJZI//r7jxeXK8TbnlMx3v+mM2IcLjcsKmjjXKXt3ABNh2LzoEsnlwjU5mKl9eHyQTgPKm43G8NuQTlk6xHfewFtgK8uNVlmbhg2FscwbTquE28T+3kJjA9Q+FgvTU+iTro6bt92Cu1aGTfVdgH+Nqao= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785564171; c=relaxed/simple; bh=PaCDEADHOiiYIku6VKXBxRoIXbypj+h3AplcGBWcDCU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jDA7wrk/YzWk7Mt6txfLV9P5Cl4o3ZAnxO0zALdKiaSiNqEwEIUlPP8onwM9//j8V1RDy3tZ/JYF1WoLRhfEPTP3SozclkADomn4sPcFElPVD70r0DP7kKpESeVuOME6uGvpHpqIM3YAql/RffNVPAkbU/XcO3sviIbo7IGI8Nw= 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=KejZUDYY; arc=none smtp.client-ip=209.85.214.169 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="KejZUDYY" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2cf52d15d88so14107165ad.2 for ; Fri, 31 Jul 2026 23:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1785564169; x=1786168969; 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=/FE8ttUnLC4/HPgKY+wP8Klu+NVFl8eobi0/CL9TYD0=; b=KejZUDYY6zKiz24zYHyeoV5GALFoptvsBMK7AaC3+lc9u5DKW57n85PkFJIW+eGskA N7Hee9mwGr7GpSetlv70++K33aVItNLW9dC/GlyFJa3tygAXsUG6vAUQ5ODz6J2h2yXM BD1WmITmF/RPpGqxO+bF7+XVVHNYBKQNAVihkrgECKGX9H/Qrksy4OJrEtN4rYPMaecw psVMnHOH5q/hzvZ4M1+cNUSowF8usxmX+QpNSl/VY6XNjuv87z9adlrcEv9V99W7/1DQ dCLD7/7QWsybWGrzPTU39NqYct3bXxl7FgcuqR9q5I9tfT8dGS+gay7tYiH62Mi+3sXD IGVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785564169; x=1786168969; 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=/FE8ttUnLC4/HPgKY+wP8Klu+NVFl8eobi0/CL9TYD0=; b=n25ki0LyQQTzrdSAZbjYOjF3J9FtHyneDlvU7He3559Jx5pG/KaKkF5wQovqwr5yMT PiJWSICTris0oQvrIE4D/2XV76Lr+nLGhSZM92biSqFwySN2v5R+/Y60JbgCLsPNoytL OD7c/ZFF1AHMjdPUTn27dpwTPV1lFRdVTYvr91V0Gp595RdVZ2KVPaD9HE03XnCzqFd+ 5FLIe3mXdbEZNm3AKNkmZZu61YB+JRfMHmoPPQ1D6eowx/v4sj5/UVz1ubVd5eHm5LIN yeRP9sE2Peih1R6+0FGqWLJd09vqqZKcgQAKVlocZyyibdFErmw1C4RFKYLfdB1X/E6u b8EQ== X-Forwarded-Encrypted: i=1; AHgh+Rp3ZAG6EqDP0S7b5JeZYMy82THQLs/sUtDc1o7kb411dyKaoGkbFwXuZuoY/VoH1Pl/rubJs2wdULZ9UAg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+wNmEQoakAPW/AfST1fAFjKEZ60cFrCkA2oOSlKME/uP1ApPf eOx8RL7fbumqu/AS5fGG+9L2JiKA2Btu+o07bmwoOTgdKfm+XYc4TOUKNk2H3tBvOBg= X-Gm-Gg: AR+sD119UuIB7WtmV3UWwBEZz+EGce0kO1VZPb3zfK4OrXbupO7ck33YG2tRS2V918s +XusReb8Lb38JO0NNlzwY/1jOn/aF7BfjQyWelNrF5CRiuZ4p9+JNQrihPyE87Tr+0Qg9N5tFgg /gj4p0voG/saT4pRffDIxa0mWvwBWmV77PUgabHzcFDdsxaEwKtStbRSIsJ+0tyIR5LG8CHZnZh xDJnLYq/hlApz3qEZq/QzMszS1Nf4XOAkTlap1Mhua3SDwqU51sSXGDfyJ5SYSf5M1tCnqY9bJg Z8DQ5hjHxjuef6j1Y75kl7hU5BAjtka/QO7S1liSOG7h1djDHLN08VDH6lPBwubmLG/YPhx6WVB OvuhQO4pO6NIA4KS8rf9Nfx9lGjWJPA70+78EpFnsA4KoBPFketMSvN09KyomRVYjvmxEHAmf// PpuEWGbk6HQFJ6tjEVbBzVjGVLcMg6ue55EXdRpZiDY4fo0NqnXp7vScgbEqUWDCqES1HLlFSwN JmVmES3CJJHfU/llO+lYcE= X-Received: by 2002:a17:90b:440d:b0:380:21b7:e727 with SMTP id 98e67ed59e1d1-38fbc438399mr2464915a91.14.1785564169033; Fri, 31 Jul 2026 23:02:49 -0700 (PDT) Received: from localhost.localdomain ([2406:5900:1044:110c:c329:7b28:fe02:5dc8]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38fb2bae2efsm1598856a91.11.2026.07.31.23.02.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 23:02:48 -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 v2 2/2] nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Date: Sat, 1 Aug 2026 15:02:01 +0900 Message-ID: <20260801060201.1879499-3-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260801060201.1879499-1-yhlee@isslab.korea.ac.kr> References: <20260801060201.1879499-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, so nvme_tcp_handle_c2h_data() still reads blk_rq_payload_bytes() itself. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(). Setup leaves req->iter untouched while the receive gate lets a C2HData through, so nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed when the tag set is allocated and never again. 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 Test req->data_len instead. It is zero whenever blk_rq_payload_bytes() is zero, so nothing the old test caught is lost, and it is additionally zero when there are no physical segments. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now asks the same two questions. Fixes: 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processi= ng") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- 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 4b72f555495d..dc2aa9b01f20 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 (!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