From: Jakub Kicinski <kuba@kernel.org>
To: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Cc: john.fastabend@gmail.com, sd@queasysnail.net,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
horms@kernel.org, netdev@vger.kernel.org, svens@linux.ibm.com,
brueckner@linux.ibm.com
Subject: Re: [PATCH net] tls: fix RX desync on overlapping skbs
Date: Tue, 11 Aug 2026 19:33:44 -0700 [thread overview]
Message-ID: <20260811193344.4b394e45@kernel.org> (raw)
In-Reply-To: <20260807173532.2256680-1-maxbr@linux.ibm.com>
On Fri, 7 Aug 2026 19:31:05 +0200 Maximilian Immanuel Brandtner wrote:
> On a reordering path (e.g. IPsec crypto offload + GRO) the TCP receive
It'd be better to move this "IPsec crypto offload + GRO" to the end,
it's not super relevant to the problem. Mention that you observe this
in real life and that "IPsec crypto offload + GRO" is the likely
culprit. Mentioning the NIC may also be useful to other users.
> queue can hold adjacent skbs whose sequence ranges overlap. The tls
> fast-path reads the record header with skb_copy_bits() by byte offset,
> which assumes skb ranges don't overlap.
> When a record boundary lands within the last few bytes of an skb, the
> 5-byte header straddles into the overlapping next skb; the duplicate bytes
> are read as the header, yielding a bogus length (-EMSGSIZE) or version
> (-EINVAL) and aborting the connection.
>
> tls_strp_check_queue_ok() already detects such overlaps and diverts to the
> seq-addressed copy path, but it only ran after the header was parsed,
The rest of this paragraph below looks like slop, don't describe what
the patch does. We can hopefully see that from the diff.
> and
> it validated stm.offset + stm.full_len -- and full_len is still 0 for a new
> record, so it could not cover the header bytes. Parameterize it by length
> and also validate the header region (stm.offset + TLS_HEADER_SIZE) before
> parsing.
>
> Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
> Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
> ---
> Tested on Linux kernel 7.2 rc6
> ---
> net/tls/tls_strp.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/net/tls/tls_strp.c b/net/tls/tls_strp.c
> index 61b10c697ecc..64d5dea90540 100644
> --- a/net/tls/tls_strp.c
> +++ b/net/tls/tls_strp.c
> @@ -430,9 +430,9 @@ static int tls_strp_read_copy(struct tls_strparser *strp, bool qshort)
> return 0;
> }
>
> -static bool tls_strp_check_queue_ok(struct tls_strparser *strp)
> +static bool tls_strp_check_queue_ok(struct tls_strparser *strp,
> + unsigned int len)
> {
> - unsigned int len = strp->stm.offset + strp->stm.full_len;
keep the stm.offset addition here, it's doesn't belong in the caller
> struct sk_buff *first, *skb;
> u32 seq;
>
> @@ -525,6 +525,12 @@ static int tls_strp_read_sock(struct tls_strparser *strp)
>
> tls_strp_load_anchor_with_queue(strp, inq);
> if (!strp->stm.full_len) {
> + if (inq < TLS_HEADER_SIZE)
> + return tls_strp_read_copy(strp, true);
> +
no empty line between the two checks
> + if (!tls_strp_check_queue_ok(strp, strp->stm.offset + TLS_HEADER_SIZE))
> + return tls_strp_read_copy(strp, false);
prev parent reply other threads:[~2026-08-12 2:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 17:31 [PATCH net] tls: fix RX desync on overlapping skbs Maximilian Immanuel Brandtner
2026-08-12 2:33 ` Jakub Kicinski [this message]
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=20260811193344.4b394e45@kernel.org \
--to=kuba@kernel.org \
--cc=brueckner@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=maxbr@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=svens@linux.ibm.com \
/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