2026-10-13, 10:55:26 -0700, Rishikesh Jethwani wrote: > On Tue, Oct 13, 2026 at 2:38 AM Sabrina Dubroca <[email protected]> wrote: > > > > 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). > > Do you have a pointer to that thread? If there's a preferred way to make > these errors sticky, I'd rather use it than add a one-off flag.
https://lore.kernel.org/all/ajFpejsl1ukTbG96@krikkit/ and I had a suggestion at the end, but I guess I got interrupted and never got back to it. > > > > 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? > > You're right, in practice there isn't one. The only way to get there is > for userspace to install a rec_seq close to the limit, so sequence 0 was > never used under that key and nothing can be replayed. Starting there > already breaks RFC 8446 5.3, which requires the first record under a > key to use sequence number 0. > > What's left is consistency. Today the wrap gives at most one EBADMSG, > and none if the next record has already been parsed. After that recv I'm not seeing the "none if the next record has already been parsed" flow. Can you describe the sequence of events? > continues at record 0, which is neither rekeying nor terminating. TX > behaves the same way: the UINT64_MAX record is queued, and it goes out > once SO_ERROR is cleared. Then why are you patching only RX here? Both are just as problematic? If we implement the "abort with (some error code) is actually final, and not cleared with sk_err" idea, all this goes away? > So I'll drop the security framing and the Fixes tag. I can either drop > the patch, or send a minimal version for net/net-next that makes the wrap > error stick on both RX and TX, without touching the rekey path. Which > would you prefer? For this, net-next should be fine. > > 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. > > Agreed, that gets rid of the fixed vectors. Since 1.3 only uses the > record number in the nonce, TX can also produce the UINT64_MAX record > cleanly, using rec_seq 0 and the IV XORed with UINT64_MAX. If the patch I don't get this rec_seq 0 and IV to reach UINT64_MAX. Why not just pass rec_seq = 0xff..., like the current recseq_wrap test? -- Sabrina
