[PATCH 0/2] nvmet-tcp: fix receive path error handling and state machine

[Maurizio Lombardi]

On Fri Mar 13, 2026 at 6:58 AM CET, yunje shin wrote:
> On Thu, Mar 12, 2026 at 1:09 AM Maurizio Lombardi <mlombard at redhat.com> wrote:
>>
>> Patch 1 fixes a potential issue where network data could be read into an
>> uninitialized iterator. Currently, nvmet_tcp_build_pdu_iovec() returns void,
>> meaning callers are unaware if an out-of-bounds PDU length or offset triggers
>> an early return. Consequently, callers blindly overwrite the queue state to
>> NVMET_TCP_RECV_DATA. This patch modifies the function to return an error code,
>> shifting the handling responsibility to the callers to ensure proper socket
>> teardown.
>
> Thank you for the patchset — the error propagation cleanup looks
> really clean and makes the receive path error handling much clearer.
>
> I've been trying to reproduce this crash scenario on my end [1],
> but I haven't been able to trigger it reliably in my test
> environment so far.

I guess that the msg_data_left(&cmd->recv_msg) check in
nvmet_tcp_try_recv_data() prevents the derefence of the uninitialized
iterator, so this is why it doesn't crash.

I see however that it tries to parse junk, so the patchset is useful
anyway, I will correct the commit message.


[  114.122436] nvmet_tcp: unexpected pdu type 75
[  114.122487] nvmet: ctrl 1 fatal error occurred!
[  124.660886] nvmet: Created nvm controller 1 for subsystem test-nqn for NQN nqn.2014-08.org.nvmexpress:uuid:eb574a60-a657-4daa-8a7d-c3c1d25033f6.
[  132.872857] nvmet_tcp: unexpected pdu type 129
[  132.872871] nvmet_tcp: unexpected pdu type 236
[  132.872880] nvmet: ctrl 1 fatal error occurred!


Maurizio