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

[Yingjie Wang]

The NVMe/TCP host and target each expose a writable
tls_handshake_timeout parameter. Both parameters are signed integers, and
both paths multiply their 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 produced a signed
integer overflow in a real target TLS connection. A real host connection
through /dev/nvme-fabrics produced overflows at both host conversion sites.

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 a concurrent update cannot give the two
timeout mechanisms different values. The patches are otherwise independent.

The exact series was tested on an x86-64 HZ=1000 KASAN/UBSAN kernel. Both
parameters rejected -1 and 4294968 without changing the current value,
accepted 4294967 and the former overflow trigger, and exercised the target
listener and host /dev/nvme-fabrics paths without a UBSAN, KASAN, warning,
BUG, or oops. The expected handshake failure was -ESRCH because tlshd was
deliberately not running.

Both changed objects also built with W=1 for x86-64 and i386. The i386
objects had no __divdi3 or __udivdi3 dependency. Arithmetic boundary checks
covered HZ values 100, 250, 300, 1000, and 1024.

AI-assisted analysis was used to trace the timeout arithmetic and prepare the
initial changes. I reviewed the final diff and the test evidence above.

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

 drivers/nvme/host/tcp.c   | 25 +++++++++++++++++++++----
 drivers/nvme/target/tcp.c | 26 ++++++++++++++++++++++----
 2 files changed, 43 insertions(+), 8 deletions(-)


base-commit: aaedcff9014876387504a8b92d227766cb95015c
-- 
2.43.0