[PATCH v2 0/2] nvme-tcp: handle TLS control records at connect and on receive errors
Keith Busch
kbusch at kernel.org
Tue Oct 27 15:53:44 PDT 2026
On Tue, Oct 27, 2026 at 06:38:51AM -0400, Martin Belanger via B4 Relay wrote:
> A TLS 1.3 peer can send records that carry no application data, for
> example a NewSessionTicket right after the handshake. nvme-tcp does not
> handle them correctly. This series fixes two cases.
>
> Patch 1: when read_sock() returns an error, nvme-tcp does not start
> error recovery. The queue stops receiving until a command times out.
> With a NewSessionTicket on a live queue, I/O stalls until the I/O
> timeout (30 seconds by default). With this patch, recovery starts at
> once. This also applies to plain TCP.
>
> Patch 2: a NewSessionTicket that arrives before the ICResp fails the
> connection with "failed to receive icresp, error -104". A target that
> sends a ticket at once, such as an OpenSSL-based target, cannot be
> reached. With this patch, the ticket is discarded and the connection
> succeeds. An alert in place of the ICResp is now reported with its code,
> instead of as error -104.
>
> These patches replace patch 1/2 of Hannes's "nvme,tls: minimal handling
> for TLS records":
> https://lore.kernel.org/all/20260922133708.84522-1-hare@kernel.org/
Thanks, applied to nvme-7.4.
More information about the Linux-nvme
mailing list