From nobody Mon Sep 28 19:24:41 2026 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 E1E3645FFB4 for ; Tue, 18 Aug 2026 11:05:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051127; cv=none; b=pc7XZ6VPNYLi30PlIgMTdwBf+oFXi4rVpNTjiTku6GFN8v/ra+/snGaUuTcRWdO6DDqyw5sDAJC0+kS/QtiLD5td9rUPx0SRgIsDGyNGDAu8kfKI8VcuMJAz2VeanMC/jJKDpl89gBw51bQLp9IlYPi81zmPDhk8TarLNesevXk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051127; c=relaxed/simple; bh=7PttoYG+N72lGp3+n6J9QSHqeN61a9qbM4HiGVTu35A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VZ2kPL6FBcCAWQLvmfaYnyr1RzVJpE//pNS9PHjyap27Ddc4f1sFqYhX+i3tGYiKnuHBMDjp3Tz6E3qkS1Dl9J9FEYPrDbezDvVcKj9mNlKDWqdZX1APsyc2d8uQ1U+JZP0Xaw47IbqrqVnxxlodvlSOpVKKUwROkx0tvgaGEr4= 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=KYRrE11e; arc=none smtp.client-ip=209.85.214.174 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="KYRrE11e" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2cedda2ce6fso29376785ad.1 for ; Tue, 18 Aug 2026 04:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1787051124; x=1787655924; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=F00tHSyJsJ6CzdE6v/TT1V5MB6XClnKFlQNlIPg7vzw=; b=KYRrE11eQZHheIf2C+D+OmCJeSpNybTxWskb5Afe63jK8UW5rPOJdS7srdR0uREgeY aQmoFXB3vq3BRZJYggLcp562GZsHIuTBVNtUbzeOKoaRfg3QZgjiaPHs51GRr2VyT8RY BeBqhhL3HaWJlDWxKnl+4U7SVAyu4uXPNPP8e73+ipaoYHRsc/06ibFzZUM9Ka0lcTMC Ip9orNX2y+8DbVqUSpbO8TXz0N0qu6/wal41rRl37cVeS0LXhp1SrHLQZPawXDgcMQxG ASte5BjeBkbsK1MGttIb2ScMpkZRbUevGNswHX5+PpUcu8Zza7XfapoAWEEvtsCLcXZa MqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787051124; x=1787655924; h=content-transfer-encoding:mime-version: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=F00tHSyJsJ6CzdE6v/TT1V5MB6XClnKFlQNlIPg7vzw=; b=hog+cRumWxJKC7W2jXWB/Ifk3pLi5WuQtc5UFBJeC4etzHZ4eHZOBzpvCu+Q/aNayh Lfh/udHJBmGhn8XncFODelpn1eLUXC0aJmjAD2R40d9BXmojUVke6i6lak0mgzB5TBpu FpaowhtEUNl5DbZ0uswkvgwNN/4NLT+Tr0dBadl1ya+lKIvZMuscF31gxXGv3NhtZQ5X R+g7e80SZFZoWj+5y3si97vkMo7aDZVh+SUofOUdDqfVRMv1NaeEG0ZxvNo0mo1uGM1t 7JFch6n7YC3nmiJ49PgpLYiJ7WiY5px0kUPdkTDRLzM/+X6TTvSs9hdfhHC+4Evin2PF fc5A== X-Forwarded-Encrypted: i=1; AHgh+RpmpSNIoLjVVSW2IVPrun452++5EEqHBL0OMmgn+uTCZxSvSwSddtDoPhFrI9OcjtY5p05rS6nAIsFGb6w=@vger.kernel.org X-Gm-Message-State: AOJu0YwfkaPQw6y2Prc1W8IzLBIwxTzUccQrVlUL+jTQ3oK7UTfxPuog 85Hw7NzC6sD1UJL+P0CwrgEz8eXxin8R/tfN6TNfm/+U3NXIZHIbwpZ0Ao9bLOy21fE= X-Gm-Gg: AR+sD13PjvS2HjPGNrYgFlsz2ztZxFNRpDNpQk5MITTcQy/MDVwn91gXFN6lABwOt7M zd7fWb9vDTHGZO8JXLEFoOQUBi2YHOzWhNx3SGfB4ybr02kzsqd7M/MZpchq30xbjspbqRH+Rs3 wtHcCUy75AcekjIExFvZq5f4m85HwOXs0y7Z3sS8wRs8yjpuFWMo5CoWB6y1LSp8F0IqBGC+Wgu zN9zqNUDknV4nLKkHHvvZNYoJFYSQWdLnhEIsLGlKlbWVIfdsu0zSWCTJOoZShQ4GkHZwOErYOz ODWAESsGHriiB06g8ZXe4xPWo5Tud30TvbQg/tUp5KBrlFFnMzDSUtxzuRoO+jl5Xthao28xniN wgG931V85Gc9biFO79r0ngjzIFiWas4ztd4peIUA+IoEvHlni+kg/OzIbxO0Sb+d3GF48LP2RZK STBbUjTAhuANOPgj6yZKVcyM9oubmXBdymMP2QTymCkUCMH7JNmQk+Sv3mN/KIPjVEQFa+ X-Received: by 2002:a17:903:2311:b0:2cf:afe8:b722 with SMTP id d9443c01a7336-2d5c5149013mr98394785ad.11.1787051123928; Tue, 18 Aug 2026 04:05:23 -0700 (PDT) Received: from yhlee-960QFG.. ([125.131.91.97]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d5bcf36500sm15298765ad.5.2026.08.18.04.05.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 04:05:23 -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] nvme-tcp: check the data direction of a C2HData PDU Date: Tue, 18 Aug 2026 20:04:05 +0900 Message-ID: <20260818110405.590548-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 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_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330,= CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0= -rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy)=20 [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Christoph Hellwig --- Applies on top of "nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone". Measured over a user-space target that answers every write with C2HData. The warning appeared in 5 of 5 runs without this patch and in none of 5 with it, in each of three shapes: a buffered 8 KiB write, a 4 KiB write carried in the command capsule, and a discard. In every run the command ids the target answered matched the ones the kernel named. A conforming target is unaffected over 5 runs each way, including writes and a passthrough read, which rq_data_dir() classifies as a read. Those runs were on 7.2-rc5 with this patch as the only change. Repeating the write, the in-capsule write and the conforming-target arms three times each on the base this patch applies to - 7.2-rc5 plus that patch and its predecessor - gave the same counts. drivers/nvme/host/tcp.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index 85a87ed6df936..a62d6e48f7190 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -679,6 +679,13 @@ static int nvme_tcp_handle_c2h_data(struct nvme_tcp_qu= eue *queue, return -ENOENT; } =20 + if (rq_data_dir(rq) !=3D READ) { + dev_err(queue->ctrl->ctrl.device, + "queue %d tag %#x unexpected data for a write\n", + nvme_tcp_queue_id(queue), rq->tag); + return -EIO; + } + 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, --=20 2.43.0