crypto/tls: prevent deadlock when client sends multiple key update messages

When we made setReadTrafficSecret send an alert when there are pending
handshake messages, we introduced a deadlock when the client sends
multiple key update messages that request a response, as handleKeyUpdate
will lock the mutex, and defer the unlocking until the end of the
function, but setReadTrafficSecret called sendAlert in the failure case,
which also tries to lock the mutex.

Add an argument to setReadTrafficSecret which lets the caller indicate
if the mutex is already locked, and if so, call sendAlertLocked instead
of sendAlert.

Thanks to Jakub Ciolek for reporting this issue.

Fixes #78334
Fixes CVE-2026-32283

Change-Id: Id8e56974233c910e0d66ba96eafbd2ea57832610
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3881
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/763767
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>

0 files changed, 0 insertions, 0 deletions