[PATCH v3] nvmet-tcp: reject H2CData before ICReq

[PATCH v3] nvmet-tcp: reject H2CData before ICReq

[YunJe Shin]

If H2CData arrives before ICReq/CONNECT, queue->connect is used but its
iov is not initialized yet, which can lead to a NULL dereference when
building the PDU iovec. Reject such requests early with -EPROTO.

Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Signed-off-by: YunJe Shin <ioerts@kookmin.ac.kr>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
---
 drivers/nvme/target/tcp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index 15416ff0eac4..e272d38f285b 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -961,6 +961,9 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 		cmd = &queue->cmds[data->ttag];
 	} else {
 		cmd = &queue->connect;
+		/* H2CData before ICReq/CONNECT: connect has no iov. */
+		if (!cmd->iov)
+			goto err_proto;
 	}
 
 	if (le32_to_cpu(data->data_offset) != cmd->rbytes_done) {
-- 
2.43.0

Re: [PATCH v3] nvmet-tcp: reject H2CData before ICReq

[Maurizio Lombardi]

On Mon Jan 26, 2026 at 7:41 AM CET, YunJe Shin wrote:
> If H2CData arrives before ICReq/CONNECT, queue->connect is used but its
> iov is not initialized yet, which can lead to a NULL dereference when
> building the PDU iovec. Reject such requests early with -EPROTO.

Is it actually reproducible?

Doesn't nvmet_tcp_done_recv_pdu() reject all unexpected PDUs
when the queue is in connecting state?

Maurizio

Re: [PATCH v3] nvmet-tcp: reject H2CData before ICReq

[Maurizio Lombardi]

On Tue Jan 27, 2026 at 2:59 PM CET, Maurizio Lombardi wrote:
> On Mon Jan 26, 2026 at 7:41 AM CET, YunJe Shin wrote:
>> If H2CData arrives before ICReq/CONNECT, queue->connect is used but its
>> iov is not initialized yet, which can lead to a NULL dereference when
>> building the PDU iovec. Reject such requests early with -EPROTO.
>
> Doesn't nvmet_tcp_done_recv_pdu() reject all unexpected PDUs
> when the queue is in connecting state?

Nevermind, now I get what you mean: you can hit the bug if you send
H2CData after ICReq but before the execution
of the connect command.

Maurizio

Re: [PATCH v3] nvmet-tcp: reject H2CData before ICReq

[Maurizio Lombardi]

On Tue Jan 27, 2026 at 3:37 PM CET, Maurizio Lombardi wrote:
>
> Nevermind, now I get what you mean: you can hit the bug if you send
> H2CData after ICReq but before the execution
> of the connect command.

I was able to reproduce the crash:

[25362.399746] BUG: kernel NULL pointer dereference, address: 000000000000000c
[25362.403368] #PF: supervisor read access in kernel mode
[25362.405451] #PF: error_code(0x0000) - not-present page

[...]

[25362.430592] Call Trace:
[25362.430945]  <TASK>
[25362.431250]  ? show_trace_log_lvl+0x1b0/0x2f0
[25362.431910]  ? show_trace_log_lvl+0x1b0/0x2f0
[25362.432507]  ? nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
[25362.433285]  ? __die_body.cold+0x8/0x12
[25362.433810]  ? page_fault_oops+0x148/0x160
[25362.434388]  ? exc_page_fault+0x73/0x160
[25362.434953]  ? asm_exc_page_fault+0x26/0x30
[25362.435573]  ? nvmet_tcp_build_pdu_iovec+0x4c/0xc0 [nvmet_tcp]
[25362.436357]  nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
[25362.437113]  nvmet_tcp_try_recv_pdu+0x1ef/0x2d0 [nvmet_tcp]
[25362.437856]  ? sched_balance_update_blocked_averages+0xdd/0x1a0
[25362.438672]  nvmet_tcp_io_work+0x70/0x8c0 [nvmet_tcp]

But it appears to have been already been fixed by commit 32b63acd78f577b332d976aa06b56e70d054cbba
(nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec)

dmesg output target-side:

[   54.436869] nvmet_tcp: queue 0: H2CData PDU received for invalid command state (ttag 43981)


Maurizio

Re: [PATCH v3] nvmet-tcp: reject H2CData before ICReq

[yunje shin]

Thanks for letting me know. I'll check it.

YunJe


On Wed, Jan 28, 2026 at 12:17 AM Maurizio Lombardi
<mlombard@bsdbackstore.eu> wrote:
>
> On Tue Jan 27, 2026 at 3:37 PM CET, Maurizio Lombardi wrote:
> >
> > Nevermind, now I get what you mean: you can hit the bug if you send
> > H2CData after ICReq but before the execution
> > of the connect command.
>
> I was able to reproduce the crash:
>
> [25362.399746] BUG: kernel NULL pointer dereference, address: 000000000000000c
> [25362.403368] #PF: supervisor read access in kernel mode
> [25362.405451] #PF: error_code(0x0000) - not-present page
>
> [...]
>
> [25362.430592] Call Trace:
> [25362.430945]  <TASK>
> [25362.431250]  ? show_trace_log_lvl+0x1b0/0x2f0
> [25362.431910]  ? show_trace_log_lvl+0x1b0/0x2f0
> [25362.432507]  ? nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
> [25362.433285]  ? __die_body.cold+0x8/0x12
> [25362.433810]  ? page_fault_oops+0x148/0x160
> [25362.434388]  ? exc_page_fault+0x73/0x160
> [25362.434953]  ? asm_exc_page_fault+0x26/0x30
> [25362.435573]  ? nvmet_tcp_build_pdu_iovec+0x4c/0xc0 [nvmet_tcp]
> [25362.436357]  nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
> [25362.437113]  nvmet_tcp_try_recv_pdu+0x1ef/0x2d0 [nvmet_tcp]
> [25362.437856]  ? sched_balance_update_blocked_averages+0xdd/0x1a0
> [25362.438672]  nvmet_tcp_io_work+0x70/0x8c0 [nvmet_tcp]
>
> But it appears to have been already been fixed by commit 32b63acd78f577b332d976aa06b56e70d054cbba
> (nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec)
>
> dmesg output target-side:
>
> [   54.436869] nvmet_tcp: queue 0: H2CData PDU received for invalid command state (ttag 43981)
>
>
> Maurizio

Re: [PATCH v3] nvmet-tcp: reject H2CData before ICReq

[yunje shin]

i agree have been already been fixed by commit
32b63acd78f577b332d976aa06b56e70d054cbba
(nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec)
but i think other thread([PATCH] nvmet-tcp: add bounds checks in
nvmet_tcp_build_pdu_iovec) slab oob is works

On Wed, Jan 28, 2026 at 9:45 AM yunje shin <yjshin0438@gmail.com> wrote:
>
> Thanks for letting me know. I'll check it.
>
> YunJe
>
>
> On Wed, Jan 28, 2026 at 12:17 AM Maurizio Lombardi
> <mlombard@bsdbackstore.eu> wrote:
> >
> > On Tue Jan 27, 2026 at 3:37 PM CET, Maurizio Lombardi wrote:
> > >
> > > Nevermind, now I get what you mean: you can hit the bug if you send
> > > H2CData after ICReq but before the execution
> > > of the connect command.
> >
> > I was able to reproduce the crash:
> >
> > [25362.399746] BUG: kernel NULL pointer dereference, address: 000000000000000c
> > [25362.403368] #PF: supervisor read access in kernel mode
> > [25362.405451] #PF: error_code(0x0000) - not-present page
> >
> > [...]
> >
> > [25362.430592] Call Trace:
> > [25362.430945]  <TASK>
> > [25362.431250]  ? show_trace_log_lvl+0x1b0/0x2f0
> > [25362.431910]  ? show_trace_log_lvl+0x1b0/0x2f0
> > [25362.432507]  ? nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
> > [25362.433285]  ? __die_body.cold+0x8/0x12
> > [25362.433810]  ? page_fault_oops+0x148/0x160
> > [25362.434388]  ? exc_page_fault+0x73/0x160
> > [25362.434953]  ? asm_exc_page_fault+0x26/0x30
> > [25362.435573]  ? nvmet_tcp_build_pdu_iovec+0x4c/0xc0 [nvmet_tcp]
> > [25362.436357]  nvmet_tcp_done_recv_pdu+0x299/0x2f0 [nvmet_tcp]
> > [25362.437113]  nvmet_tcp_try_recv_pdu+0x1ef/0x2d0 [nvmet_tcp]
> > [25362.437856]  ? sched_balance_update_blocked_averages+0xdd/0x1a0
> > [25362.438672]  nvmet_tcp_io_work+0x70/0x8c0 [nvmet_tcp]
> >
> > But it appears to have been already been fixed by commit 32b63acd78f577b332d976aa06b56e70d054cbba
> > (nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec)
> >
> > dmesg output target-side:
> >
> > [   54.436869] nvmet_tcp: queue 0: H2CData PDU received for invalid command state (ttag 43981)
> >
> >
> > Maurizio