[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180917.080457.483898191006335332.davem@davemloft.net>
Date: Mon, 17 Sep 2018 08:04:57 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: daniel@...earbox.net
Cc: davejwatson@...com, doronrk@...com, alexei.starovoitov@...il.com,
john.fastabend@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] tls: fix currently broken MSG_PEEK behavior
From: Daniel Borkmann <daniel@...earbox.net>
Date: Fri, 14 Sep 2018 23:00:55 +0200
> In kTLS MSG_PEEK behavior is currently failing, strace example:
...
> As can be seen from strace, there are two TLS records sent,
> i) 'test_read_peek' and ii) '_mult_recs\0' where we end up
> peeking 'test_read_peektest_read_peektest'. This is clearly
> wrong, and what happens is that given peek cannot call into
> tls_sw_advance_skb() to unpause strparser and proceed with
> the next skb, we end up looping over the current one, copying
> the 'test_read_peek' over and over into the user provided
> buffer.
>
> Here, we can only peek into the currently held skb (current,
> full TLS record) as otherwise we would end up having to hold
> all the original skb(s) (depending on the peek depth) in a
> separate queue when unpausing strparser to process next
> records, minimally intrusive is to return only up to the
> current record's size (which likely was what c46234ebb4d1
> ("tls: RX path for ktls") originally intended as well). Thus,
> after patch we properly peek the first record:
...
> Fixes: c46234ebb4d1 ("tls: RX path for ktls")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
Applied and queued up for -stable.
Powered by blists - more mailing lists