Netdev List
 help / color / mirror / Atom feed
From: Rishikesh Jethwani <rjethwani@purestorage.com>
To: netdev@vger.kernel.org
Cc: Rishikesh Jethwani <rjethwani@purestorage.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Sabrina Dubroca <sd@queasysnail.net>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH net v2 3/4] tls: device: fix record start reported to RX resync in copy mode
Date: Thu, 22 Oct 2026 16:14:59 -0600	[thread overview]
Message-ID: <20261022221732.1397620-4-rjethwani@purestorage.com> (raw)
In-Reply-To: <20261022221732.1397620-1-rjethwani@purestorage.com>

tls_rx_msg_size() tells the device layer where each new record starts,
via tls_device_rx_resync_new_rec(), as TCP_SKB_CB(skb)->seq +
strp->stm.offset. skb is the strparser anchor, whose cb is copied from
the first queued skb by tls_strp_load_anchor_with_queue(), and
stm.offset is where the record starts within that skb.

When the header cannot be parsed in place, tls_strp_read_copy() moves
the strparser to copy mode and resets stm.offset to 0, but the anchor
keeps the first skb's cb. The header is then parsed from the copied
data, and the reported start is the first byte of that skb rather than
of the record. If the record does not begin at an skb boundary, the
sequence is too low by the record's offset into the skb.

Every resync type compares or advances that sequence. With
TLS_OFFLOAD_SYNC_TYPE_DRIVER_REQ and DRIVER_REQ_ASYNC the device's
request no longer matches and the resync is missed until a later
record. With TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT the device is given a
next-record boundary that is off by the same amount.

The header is parsed in copy mode when fewer bytes than the TLS header
plus explicit IV, where applicable, are queued under memory pressure or
with a collapsed receive window, or when the header straddles skbs that
overlap or differ in decrypted status. The latter is most likely right
around a loss of device sync, when resync is needed. Commit 9466ef3ec972
("tls: fix RX desync on overlapping skbs") added that queue-consistency
check before the header is parsed; before it only a short queue led
here.

The strparser now records the start of each record before it can enter
copy mode, so report strp->seq instead.

Found by code inspection while working on TLS 1.3 hardware offload
support.

Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
 net/tls/tls_sw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d1ad31986cf2..5db4a6897b29 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2232,7 +2232,7 @@ int tls_rx_msg_size(struct tls_strparser *strp, struct sk_buff *skb)
 	}
 
 	tls_device_rx_resync_new_rec(strp->sk, data_len + TLS_HEADER_SIZE,
-				     TCP_SKB_CB(skb)->seq + strp->stm.offset);
+				     strp->seq);
 	return data_len + TLS_HEADER_SIZE;
 
 read_failure:
-- 
2.50.1


  parent reply	other threads:[~2026-10-22 22:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 22:14 [PATCH net v2 0/4] tls: device: fix RX record start tracking after strparser rework Rishikesh Jethwani
2026-10-22 22:14 ` [PATCH net v2 1/4] tls: device: fix record start in the tls_device_decrypted tracepoint Rishikesh Jethwani
2026-10-22 22:14 ` [PATCH net v2 2/4] tls: device: fix next-record sequence in core-driven RX resync Rishikesh Jethwani
2026-10-26 22:48   ` netdev-bot+sashiko
2026-10-27 17:52     ` Rishikesh Jethwani
2026-10-22 22:14 ` Rishikesh Jethwani [this message]
2026-10-22 22:15 ` [PATCH net v2 4/4] tls: device: fix next-record queued checks " 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=20261022221732.1397620-4-rjethwani@purestorage.com \
    --to=rjethwani@purestorage.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    /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