[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190612.110547.28991361423569318.davem@davemloft.net>
Date: Wed, 12 Jun 2019 11:05:47 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: john.fastabend@...il.com
Cc: steinar+kernel@...derson.no, daniel@...earbox.net, andre@...t.net,
netdev@...r.kernel.org, ast@...nel.org
Subject: Re: [net PATCH v2] net: tls, correctly account for copied bytes
with multiple sk_msgs
From: John Fastabend <john.fastabend@...il.com>
Date: Wed, 12 Jun 2019 17:23:57 +0000
> tls_sw_do_sendpage needs to return the total number of bytes sent
> regardless of how many sk_msgs are allocated. Unfortunately, copied
> (the value we return up the stack) is zero'd before each new sk_msg
> is allocated so we only return the copied size of the last sk_msg used.
>
> The caller (splice, etc.) of sendpage will then believe only part
> of its data was sent and send the missing chunks again. However,
> because the data actually was sent the receiver will get multiple
> copies of the same data.
>
> To reproduce this do multiple sendfile calls with a length close to
> the max record size. This will in turn call splice/sendpage, sendpage
> may use multiple sk_msg in this case and then returns the incorrect
> number of bytes. This will cause splice to resend creating duplicate
> data on the receiver. Andre created a C program that can easily
> generate this case so we will push a similar selftest for this to
> bpf-next shortly.
>
> The fix is to _not_ zero the copied field so that the total sent
> bytes is returned.
>
> Reported-by: Steinar H. Gunderson <steinar+kernel@...derson.no>
> Reported-by: Andre Tomt <andre@...t.net>
> Tested-by: Andre Tomt <andre@...t.net>
> Fixes: d829e9c4112b ("tls: convert to generic sk_msg interface")
> Signed-off-by: John Fastabend <john.fastabend@...il.com>
Applied and queued up for -stable.
Powered by blists - more mailing lists