Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2237467ybi; Thu, 20 Jun 2019 11:22:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnveALpbd/lVrWo8DASXgG9sOIFQqepm9cqIJXujEt04hAlIdKgg7rvBS5H5i/dH6IefQr X-Received: by 2002:a65:41c7:: with SMTP id b7mr13969362pgq.165.1561054975368; Thu, 20 Jun 2019 11:22:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561054975; cv=none; d=google.com; s=arc-20160816; b=esciPefJK/tffsW5x3XgpQdduEhVHg24Hiud/jucAbj8R1fPT7mkcoqdroESUVhTIS KZmQDf7Fb4iYKSYgmDskdEbJ9+VVqCI3Fz6HV2tI3ZXl2DfeOZ4U7+tilJZKAZFnaRlK b/mtWa7Ae2aBKlSDQO2qXUm9NRX2FNdjyD8/IoCiRdwQoDhudv5eTdnlp7XJAwa8c5oE G79yQ50QCbftupH7v5mDzKGiWNm80sUXtJE0uB0UoDNZNgk312Krryhnbtia2+1/Y9Rk OHvvAQQnURVvvBSOwMuPKHg6+MXzBBbLxapKKcVS6ikpx3neVSA9sTQdcLspZnUH4aCA xdfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=c6u0E+M+QjBp2gCVwF2YuGne9l3EQ7Zk+KOgW4/77Fk=; b=G/mJtHuWHKnc+DI4K4MV6woVBS44TaJcsP6PKwM9+sPmYPsKEjCBQ9Y6siEmv7hx/N bxXQqX/jqrz23NVWEui7FK0BOIBE4x7Nj9Chj6mfkMq4a7+rd6JYcr+CagzvSyEBog36 Jnq1gPddlNnPpO7DL83NoQ6Nyfqs9JHuXQp/KYYbF2zzT4WU+qEsyAqULldgO8j7APKt drkdXqfC5J9A7VjNw5rzUst0kVkVFHsgnpdDwnSjezL0azNswR/kEJ2VLZglA1Cykd4z YPvJpdoMc84LWN/l2xmhx5uCOwd6GSoOn/UfBOV9B+gmD0YrwXsf08IAUOV4Zlekqrv3 1M7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="CAEh/IOx"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d1si151598pgv.552.2019.06.20.11.22.40; Thu, 20 Jun 2019 11:22:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="CAEh/IOx"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728244AbfFTSNL (ORCPT + 99 others); Thu, 20 Jun 2019 14:13:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:40984 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729166AbfFTSNE (ORCPT ); Thu, 20 Jun 2019 14:13:04 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6C5582089C; Thu, 20 Jun 2019 18:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561054383; bh=Egf73Uthvql39YGQPG2N1+kk+ff3ZyCN98Dwq0WQUj4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CAEh/IOxdRXhR4WskXmnv6fv2kvT62Isp7cE40CUMVrR11yy7ERcX90BjPLl2T5AS QNxuarU2qKqFuaJ9epSpX4ft1FBfPbV5Z0P8PgN/rywEgRLRP+6BmD//WWC9uiJ3FC OdABTGqHCQV4J5INwymJR5BthLe/X+UcpsmF9g7A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Steinar H. Gunderson" , Andre Tomt , John Fastabend , "David S. Miller" Subject: [PATCH 5.1 10/98] net: tls, correctly account for copied bytes with multiple sk_msgs Date: Thu, 20 Jun 2019 19:56:37 +0200 Message-Id: <20190620174349.816327593@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190620174349.443386789@linuxfoundation.org> References: <20190620174349.443386789@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: John Fastabend [ Upstream commit 648ee6cea7dde4a5cdf817e5d964fd60b22006a4 ] 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 Reported-by: Andre Tomt Tested-by: Andre Tomt Fixes: d829e9c4112b ("tls: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/tls/tls_sw.c | 1 - 1 file changed, 1 deletion(-) --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1128,7 +1128,6 @@ static int tls_sw_do_sendpage(struct soc full_record = false; record_room = TLS_MAX_PAYLOAD_SIZE - msg_pl->sg.size; - copied = 0; copy = size; if (copy >= record_room) { copy = record_room;