From e68cc75ecdd1cfad78e586c40e19b134e2bafa53 Mon Sep 17 00:00:00 2001 From: Juliusz Sosinowicz Date: Thu, 11 Jun 2026 19:22:36 +0000 Subject: [PATCH] F-5813: clarify BuildMessage sequence-number wrap comment The sequence number 2^64-1 is itself RFC 5246 6.1-legal; only the wrap to 0 is forbidden. GetSEQIncrement reads the current counter then post-increments it, so the check refuses the final legal sequence number to avoid the wrapping post-increment. Document that this last value is deliberately sacrificed rather than implying 2^64-1 is itself unusable. --- src/internal.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/internal.c b/src/internal.c index 8fd6e50db2..a825f3ff42 100644 --- a/src/internal.c +++ b/src/internal.c @@ -24777,11 +24777,11 @@ int BuildMessage(WOLFSSL* ssl, byte* output, int outSz, const byte* input, #endif #ifndef WOLFSSL_NO_TLS12 - /* RFC 5246 6.1: record sequence numbers MUST NOT wrap. Refuse to emit a - * record once the write sequence number has reached its maximum value - * (2^64-1); reusing sequence number 0 with the same keys would break the - * record protection. The caller must renegotiate or close the connection - * instead. DTLS sequence numbers are epoch-scoped and handled elsewhere. */ + /* RFC 5246 6.1: sequence numbers MUST NOT wrap. GetSEQIncrement post- + * increments, so refuse at hi == lo == 0xFFFFFFFF (2^64-1): that last legal + * value is deliberately sacrificed to avoid wrapping to 0 and reusing + * sequence number 0. The caller must renegotiate or close. DTLS sequence + * numbers are epoch-scoped and handled elsewhere. */ if (!sizeOnly && !ssl->options.dtls && ssl->keys.sequence_number_hi == 0xFFFFFFFFU && ssl->keys.sequence_number_lo == 0xFFFFFFFFU) {