[PATCH v2 3/4] nvmet-tcp: fix handling of tls alerts
Olga Kornievskaia
aglo at umich.edu
Fri Sep 5 09:10:21 PDT 2025
Dear NvME maintainers,
Are there objections to this patch? What's the path forward to
including it in the nvme code.
Thank you.
On Thu, Jul 31, 2025 at 2:01 PM Olga Kornievskaia <okorniev at redhat.com> wrote:
>
> Revert kvec msg iterator before trying to process a TLS alert
> when possible.
>
> In nvmet_tcp_try_recv_data(), it's assumed that no msg control
> message buffer is set prior to sock_recvmsg(). Hannes suggested
> that upon detecting that TLS control message is received log a
> message and error out. Left comments in the code for the future
> improvements.
>
> Fixes: a1c5dd8355b1 ("nvmet-tcp: control messages for recvmsg()")
> Suggested-by: Hannes Reinecke <hare at suse.de>
> Reviewed-by: Hannes Reinecky <hare at susu.de>
> Signed-off-by: Olga Kornievskaia <okorniev at redhat.com>
> ---
> drivers/nvme/target/tcp.c | 31 +++++++++++++++++++------------
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
> index 688033b88d38..98cee10de713 100644
> --- a/drivers/nvme/target/tcp.c
> +++ b/drivers/nvme/target/tcp.c
> @@ -120,7 +120,6 @@ struct nvmet_tcp_cmd {
> u32 pdu_len;
> u32 pdu_recv;
> int sg_idx;
> - char recv_cbuf[CMSG_LEN(sizeof(char))];
> struct msghdr recv_msg;
> struct bio_vec *iov;
> u32 flags;
> @@ -1161,6 +1160,7 @@ static int nvmet_tcp_try_recv_pdu(struct nvmet_tcp_queue *queue)
> if (unlikely(len < 0))
> return len;
> if (queue->tls_pskid) {
> + iov_iter_revert(&msg.msg_iter, len);
> ret = nvmet_tcp_tls_record_ok(queue, &msg, cbuf);
> if (ret < 0)
> return ret;
> @@ -1217,19 +1217,28 @@ static void nvmet_tcp_prep_recv_ddgst(struct nvmet_tcp_cmd *cmd)
> static int nvmet_tcp_try_recv_data(struct nvmet_tcp_queue *queue)
> {
> struct nvmet_tcp_cmd *cmd = queue->cmd;
> - int len, ret;
> + int len;
>
> while (msg_data_left(&cmd->recv_msg)) {
> + /* to detect that we received a TlS alert, we assumed that
> + * cmg->recv_msg's control buffer is not setup. kTLS will
> + * return an error when no control buffer is set and
> + * non-tls-data payload is received.
> + */
> len = sock_recvmsg(cmd->queue->sock, &cmd->recv_msg,
> cmd->recv_msg.msg_flags);
> + if (cmd->recv_msg.msg_flags & MSG_CTRUNC) {
> + if (len == 0 || len == -EIO) {
> + pr_err("queue %d: unhandled control message\n",
> + queue->idx);
> + /* note that unconsumed TLS control message such
> + * as TLS alert is still on the socket.
> + */
> + return -EAGAIN;
> + }
> + }
> if (len <= 0)
> return len;
> - if (queue->tls_pskid) {
> - ret = nvmet_tcp_tls_record_ok(cmd->queue,
> - &cmd->recv_msg, cmd->recv_cbuf);
> - if (ret < 0)
> - return ret;
> - }
>
> cmd->pdu_recv += len;
> cmd->rbytes_done += len;
> @@ -1267,6 +1276,7 @@ static int nvmet_tcp_try_recv_ddgst(struct nvmet_tcp_queue *queue)
> if (unlikely(len < 0))
> return len;
> if (queue->tls_pskid) {
> + iov_iter_revert(&msg.msg_iter, len);
> ret = nvmet_tcp_tls_record_ok(queue, &msg, cbuf);
> if (ret < 0)
> return ret;
> @@ -1453,10 +1463,6 @@ static int nvmet_tcp_alloc_cmd(struct nvmet_tcp_queue *queue,
> if (!c->r2t_pdu)
> goto out_free_data;
>
> - if (queue->state == NVMET_TCP_Q_TLS_HANDSHAKE) {
> - c->recv_msg.msg_control = c->recv_cbuf;
> - c->recv_msg.msg_controllen = sizeof(c->recv_cbuf);
> - }
> c->recv_msg.msg_flags = MSG_DONTWAIT | MSG_NOSIGNAL;
>
> list_add_tail(&c->entry, &queue->free_list);
> @@ -1736,6 +1742,7 @@ static int nvmet_tcp_try_peek_pdu(struct nvmet_tcp_queue *queue)
> return len;
> }
>
> + iov_iter_revert(&msg.msg_iter, len);
> ret = nvmet_tcp_tls_record_ok(queue, &msg, cbuf);
> if (ret < 0)
> return ret;
> --
> 2.47.1
>
>
More information about the Linux-nvme
mailing list