* [PATCH] nvme-tcp: fix host memory disclosure on R2T for a read command
@ 2026-07-29 5:46 Yehyeong Lee
2026-08-11 0:39 ` Keith Busch
0 siblings, 1 reply; 2+ messages in thread
From: Yehyeong Lee @ 2026-07-29 5:46 UTC (permalink / raw)
To: linux-nvme
Cc: kbusch, axboe, hch, sagi, linux-kernel, Yehyeong Lee, stable,
Solganik Alexander, Roy Shterman
nvme_tcp_handle_r2t() does not check the direction of the request the
R2T refers to. A malicious controller can send an R2T for a READ and
the host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the
H2CData header and nvme_tcp_try_send_data() sends the request's data
buffer. That buffer is the READ destination, so its contents go to the
controller.
The command then completes normally and nothing is logged.
Against a test controller that answers every READ with an R2T, a 4096
byte buffered read returned all 4096 bytes, split over two R2Ts. The
pages contained stale kernel data, including an array of struct page
pointers.
Reject an R2T for a request that is not a write.
Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
---
c2hdata has the same gap - nvme_tcp_handle_c2h_data() doesn't check
direction either - but a write's iterator is ITER_SOURCE, so
_copy_to_iter() refuses the copy. It does that with WARN_ON_ONCE(),
which a controller can then trigger remotely. That seems like a
separate problem; I haven't looked at it properly yet.
Tested on v7.2-rc5 with a controller that answers every READ with an
R2T. 68 of 68 H2CData PDUs came back with the read buffer before the
patch, none after. Writes larger than the inline capsule size still go
through the normal R2T path.
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 ba5c7b3e2a7c..07cda97ffab6 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -745,6 +745,13 @@ static int nvme_tcp_handle_r2t(struct nvme_tcp_queue *queue,
}
req = blk_mq_rq_to_pdu(rq);
+ if (unlikely(rq_data_dir(rq) != WRITE)) {
+ dev_err(queue->ctrl->ctrl.device,
+ "req %d unexpected r2t for a non-write command\n",
+ rq->tag);
+ return -EPROTO;
+ }
+
if (unlikely(!r2t_length)) {
dev_err(queue->ctrl->ctrl.device,
"req %d r2t len is %u, probably a bug...\n",
--
2.43.0
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] nvme-tcp: fix host memory disclosure on R2T for a read command
2026-07-29 5:46 [PATCH] nvme-tcp: fix host memory disclosure on R2T for a read command Yehyeong Lee
@ 2026-08-11 0:39 ` Keith Busch
0 siblings, 0 replies; 2+ messages in thread
From: Keith Busch @ 2026-08-11 0:39 UTC (permalink / raw)
To: Yehyeong Lee
Cc: linux-nvme, axboe, hch, sagi, linux-kernel, stable,
Solganik Alexander, Roy Shterman
On Wed, Jul 29, 2026 at 02:46:02PM +0900, Yehyeong Lee wrote:
> nvme_tcp_handle_r2t() does not check the direction of the request the
> R2T refers to. A malicious controller can send an R2T for a READ and
> the host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the
> H2CData header and nvme_tcp_try_send_data() sends the request's data
> buffer. That buffer is the READ destination, so its contents go to the
> controller.
>
> The command then completes normally and nothing is logged.
>
> Against a test controller that answers every READ with an R2T, a 4096
> byte buffered read returned all 4096 bytes, split over two R2Ts. The
> pages contained stale kernel data, including an array of struct page
> pointers.
>
> Reject an R2T for a request that is not a write.
Looks good to me. Applied to nvme-7.3.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-11 0:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-29 5:46 [PATCH] nvme-tcp: fix host memory disclosure on R2T for a read command Yehyeong Lee
2026-08-11 0:39 ` Keith Busch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®