All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Rishikesh Jethwani <rjethwani@purestorage.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] tls: refuse RX records after record-number exhaustion
Date: Tue, 13 Oct 2026 11:38:00 +0200	[thread overview]
Message-ID: <as37-A3DKONrFuxs@krikkit> (raw)
In-Reply-To: <20261013002701.1957686-1-rjethwani@purestorage.com>

2026-10-12, 18:27:01 -0600, Rishikesh Jethwani wrote:
> A receive socket records sequence-number exhaustion only in sk_err.
> After processing record UINT64_MAX, it advances the counter to zero and
> reports EBADMSG, but SO_ERROR or sock_error() can clear that error.

I vaguely remember a discussion around making some fatal errors more
permanent (ie not use sk_err).

> parser-ready record also bypasses the socket-error check in the record
> wait. The receiver can then accept a record authenticated for sequence
> zero under the same exhausted key.

I guess, but what's the problem with wrapping as long as we don't
reuse the same record number?

> Getting there needs an initial record number installed close to the
> limit, since 2^64 records cannot be exchanged in practice, and a peer
> that sends the wrapped record, which the Linux TX path refuses to do.
> 
> Mark the RX key exhausted when its record number wraps, and refuse to
> wait for or decrypt another record under it, or to replace the key.
> Plaintext that is already decrypted can still be read. RFC 8446 lets a
> sender retire a key with a KeyUpdate as its last record, so in that
> case leave sk_err alone, report the pending key update as usual and
> let the new TLS_RX key clear the mark.
> 
> Add fixed AES-GCM wire vectors and TLS 1.2/1.3 selftests for queued
> wrapped records, SO_ERROR clearing, splice, peek, partial reads, TLS
> 1.3 key replacement and a KeyUpdate in the last record. Every case
> first verifies the penultimate record succeeds. The vectors avoid a
> userspace crypto dependency and the TX path's refusal to generate the
> maximum-number record.

For 1.3, just do a "silent rekey" (change the key but don't send a
keyupdate) on the TX side to record number 0 with the same key? And it
should be enough to test this with just 1.3.

> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index fbb274287aa5..63bef0153182 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -730,6 +730,15 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
>  			conf = TLS_SW;
>  		}
>  	} else {
> +		struct tls_sw_context_rx *rx_ctx = tls_sw_ctx_rx(ctx);
> +
> +		/* Only a KeyUpdate may follow the last record number */
> +		if (update && rx_ctx->rec_seq_exhausted &&
> +		    !rx_ctx->key_update_pending) {

I'm really confused by this.

> +			rc = -EBADMSG;
> +			goto err_crypto_info;
> +		}
> +

-- 
Sabrina

  parent reply	other threads:[~2026-10-13  9:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  0:27 [PATCH net] tls: refuse RX records after record-number exhaustion Rishikesh Jethwani
2026-10-13  0:29 ` netdev-bot+sinfo
2026-10-13  9:38 ` Sabrina Dubroca [this message]
2026-10-13 17:55   ` Rishikesh Jethwani

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=as37-A3DKONrFuxs@krikkit \
    --to=sd@queasysnail.net \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rjethwani@purestorage.com \
    --cc=skhan@linuxfoundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.