[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64311360-e363-133c-6862-4de1298942ee@novek.ru>
Date: Mon, 23 Nov 2020 13:40:46 +0000
From: Vadim Fedorenko <vfedorenko@...ek.ru>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Boris Pismenny <borisp@...dia.com>,
Aviad Yehezkel <aviadye@...dia.com>, netdev@...r.kernel.org
Subject: Re: [net v3] net/tls: missing received data after fast remote close
On 20.11.2020 18:26, Jakub Kicinski wrote:
> On Thu, 19 Nov 2020 18:59:48 +0300 Vadim Fedorenko wrote:
>> In case when tcp socket received FIN after some data and the
>> parser haven't started before reading data caller will receive
>> an empty buffer. This behavior differs from plain TCP socket and
>> leads to special treating in user-space.
>> The flow that triggers the race is simple. Server sends small
>> amount of data right after the connection is configured to use TLS
>> and closes the connection. In this case receiver sees TLS Handshake
>> data, configures TLS socket right after Change Cipher Spec record.
>> While the configuration is in process, TCP socket receives small
>> Application Data record, Encrypted Alert record and FIN packet. So
>> the TCP socket changes sk_shutdown to RCV_SHUTDOWN and sk_flag with
>> SK_DONE bit set. The received data is not parsed upon arrival and is
>> never sent to user-space.
>>
>> Patch unpauses parser directly if we have unparsed data in tcp
>> receive queue.
>>
>> Signed-off-by: Vadim Fedorenko <vfedorenko@...ek.ru>
> Applied, thanks!
Looks like I missed fixes tag to queue this patch to -stable.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Powered by blists - more mailing lists