[PATCH v3 0/2] nvme-tcp: validate TLS handshake timeout parameters

[PATCH v3 0/2] nvme-tcp: validate TLS handshake timeout parameters

[Yingjie Wang]

The NVMe/TCP host and target expose writable tls_handshake_timeout
parameters as signed integers. Both paths multiply the value by
MSEC_PER_SEC and HZ before converting the results to unsigned timeout
types. Large positive and negative values can therefore give the
handshake agent and the kernel different, unintended timeouts.

On an HZ=1000 kernel, setting the parameter to 2147484 overflows both
multiplications. On the target, an accepted pending request can queue the
timeout work on the next timer-wheel advance while the handshake agent
was given about 24.9 days. On the host, schedule_timeout() can report a
wrong timeout value with a stack dump and fail the handshake immediately.

Make each parameter unsigned and reject values that do not fit both the
handshake agent's millisecond field and a safe jiffies delay. Read the
parameter once per handshake so the two timeout mechanisms use the same
value. Also keep the host completion-wait result in a long: a successful
wait can return more than INT_MAX remaining jiffies for an accepted
timeout.

The exact v3 series was built as a complete x86-64 kernel. Both changed
objects also built with W=1 for x86-64 and i386, and the i386 objects had
no 64-bit division helper dependency.

On an x86-64 HZ=1000 KASAN/UBSAN QEMU guest, both parameters rejected -1
and 4294968 without changing the current value, accepted 0, 4294967 and
the former overflow trigger, and exercised the target listener and host
/dev/nvme-fabrics paths without a kernel diagnostic. The expected
handshake failure was -ESRCH because tlshd was deliberately not running.

A focused in-kernel completion test used an already completed completion
and a 2147484-second timeout. The wait returned 2147484000 remaining
jiffies, greater than INT_MAX, and the v3 result mapping returned success.

Changes since v2:
- clarify which documented timeout belongs to the NVMe/TCP host and
  target, as suggested by Randy Dunlap;
- add Hannes Reinecke's Reviewed-by tags to both patches;
- rebase from aaedcff90148 to nvme-7.4 commit 9afc1b71d963.

v2: https://lists.infradead.org/pipermail/linux-nvme/2026-October/066922.html
Documentation review: https://lists.infradead.org/pipermail/linux-nvme/2026-October/066933.html
Target review: https://lists.infradead.org/pipermail/linux-nvme/2026-October/066956.html
Host review: https://lists.infradead.org/pipermail/linux-nvme/2026-October/066957.html

Yingjie Wang (2):
  nvmet-tcp: validate the TLS handshake timeout
  nvme-tcp: validate the TLS handshake timeout

 .../admin-guide/kernel-parameters.txt         | 10 ++++++
 drivers/nvme/host/tcp.c                       | 34 ++++++++++++++-----
 drivers/nvme/target/tcp.c                     | 26 +++++++++++---
 3 files changed, 58 insertions(+), 12 deletions(-)


base-commit: 9afc1b71d963090e2f2aa5b2f390957823ae943b
-- 
2.43.0

Re: [PATCH v3 0/2] nvme-tcp: validate TLS handshake timeout parameters

[Keith Busch]

On Wed, Oct 28, 2026 at 07:57:18PM +0800, Yingjie Wang wrote:
> The NVMe/TCP host and target expose writable tls_handshake_timeout
> parameters as signed integers. Both paths multiply the value by
> MSEC_PER_SEC and HZ before converting the results to unsigned timeout
> types. Large positive and negative values can therefore give the
> handshake agent and the kernel different, unintended timeouts.
> 
> On an HZ=1000 kernel, setting the parameter to 2147484 overflows both
> multiplications. On the target, an accepted pending request can queue the
> timeout work on the next timer-wheel advance while the handshake agent
> was given about 24.9 days. On the host, schedule_timeout() can report a
> wrong timeout value with a stack dump and fail the handshake immediately.
> 
> Make each parameter unsigned and reject values that do not fit both the
> handshake agent's millisecond field and a safe jiffies delay. Read the
> parameter once per handshake so the two timeout mechanisms use the same
> value. Also keep the host completion-wait result in a long: a successful
> wait can return more than INT_MAX remaining jiffies for an accepted
> timeout.

Thanks, applied to nvme-7.4.