Received: by 10.223.185.116 with SMTP id b49csp6398362wrg; Wed, 28 Feb 2018 08:45:36 -0800 (PST) X-Google-Smtp-Source: AH8x226I1jnlIjaG6zMwImu9QYzZ4RSI5nErSHCrbRHhYQk6DXNTGgKeuMywyDZ5skXqpQ336X/v X-Received: by 10.98.152.205 with SMTP id d74mr18469473pfk.115.1519836336613; Wed, 28 Feb 2018 08:45:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519836336; cv=none; d=google.com; s=arc-20160816; b=CqV/zXdoRr7YMWw1fR0pHHu9dJ8rLsofxwdZ2/ZAtwKgrDCelPHady6IJ/za3xk020 CWIkSDjYc2P4sj0BasOVHgT8CWkwHM+laDwTBgkrrhcS5FOIkwk3ECorpw7PXv9tdNNn BTRJBA5BOW5r+4yamAycXjY8EweGw/sgoowG0peG1pzNQ+Cahw8RuRyg2ojxCTGNUWY5 aLYFgHLgwQR3/QmeJMn6O4Buwr/H751PWNft0Ab6xe/3p9pU9nQEk626g3RoCzSJIROf LDJVzojZAlow72npB0kCMIJqrzm0N+orx4zu3g6DWSn0sXqVi/cHdaeUmJaAGbu0/7aa Sl8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=bVFqDTPYKTZ/TIOkbsWihBah36NZbmXrnvRhBseY5nY=; b=cQH3800E8DW7JgaKxdzlimdOMliRsnrm9AUlrEU0KHfEsdFOlUeXNpVnThzRUuM68e xkRTQICWoPLGllzFIf1up7XN6UVgWnlMQ1BnB76UJRL1R0LbZVxXNy0Ohb59HLOfdveZ pXv0z4L8W0FEl1GDhQjpxnGS22wj+4SoZRMKY+SeJXnWwVwKAbsONut5VE52ZPmjD6jB 9PXnWL1rityoRa8AauFGE8hFAaFlRfFl77P29dcNo03JqN5Uui9i1ZObb4+xfzc21gGh SywRvzJHlOTrXFRsuaDMV0Omheev72zzcB4iBei5QIMlHRSPpwi9fMFUGbZAG5z9vHsE EK/Q== ARC-Authentication-Results: i=1; mx.google.com; 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 t11-v6si1542315plz.214.2018.02.28.08.45.21; Wed, 28 Feb 2018 08:45:36 -0800 (PST) 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; 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 S932714AbeB1Qoi (ORCPT + 99 others); Wed, 28 Feb 2018 11:44:38 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34679 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932091AbeB1QAk (ORCPT ); Wed, 28 Feb 2018 11:00:40 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yt-0006kw-DA; Wed, 28 Feb 2018 15:22:31 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yf-0008Vg-R9; Wed, 28 Feb 2018 15:22:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Christoph Paasch" , "David S. Miller" , "Eric Dumazet" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 090/254] tcp md5sig: Use skb's saddr when replying to an incoming segment In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Christoph Paasch commit 30791ac41927ebd3e75486f9504b6d2280463bf0 upstream. The MD5-key that belongs to a connection is identified by the peer's IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying to an incoming segment from tcp_check_req() that failed the seq-number checks. Thus, to find the correct key, we need to use the skb's saddr and not the daddr. This bug seems to have been there since quite a while, but probably got unnoticed because the consequences are not catastrophic. We will call tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer, thus the connection doesn't really fail. Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().") Signed-off-by: Christoph Paasch Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings --- net/ipv4/tcp_ipv4.c | 2 +- net/ipv6/tcp_ipv6.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -809,7 +809,7 @@ static void tcp_v4_reqsk_send_ack(struct tcp_time_stamp, req->ts_recent, 0, - tcp_md5_do_lookup(sk, (union tcp_md5_addr *)&ip_hdr(skb)->daddr, + tcp_md5_do_lookup(sk, (union tcp_md5_addr *)&ip_hdr(skb)->saddr, AF_INET), inet_rsk(req)->no_srccheck ? IP_REPLY_ARG_NOSRCCHECK : 0, ip_hdr(skb)->tos); --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -941,7 +941,7 @@ static void tcp_v6_reqsk_send_ack(struct tcp_rsk(req)->snt_isn + 1 : tcp_sk(sk)->snd_nxt, tcp_rsk(req)->rcv_nxt, req->rcv_wnd, tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if, - tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr), + tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->saddr), 0, 0); }