From: Yingjie Wang <1075151112@qq.com>
To: linux-nvme@lists.infradead.org
Cc: kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
kch@nvidia.com, hare@suse.de, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] nvme-tcp: validate TLS handshake timeout parameters
Date: Tue, 27 Oct 2026 17:35:50 +0800 [thread overview]
Message-ID: <tencent_4FCBC113A5FF944F82A007AB2D4F06A2EF07@qq.com> (raw)
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
reply other threads:[~2026-10-27 9:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tencent_4FCBC113A5FF944F82A007AB2D4F06A2EF07@qq.com \
--to=1075151112@qq.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®