Received: by 10.223.176.5 with SMTP id f5csp702105wra; Fri, 9 Feb 2018 05:57:40 -0800 (PST) X-Google-Smtp-Source: AH8x226eJt9GfzDxpdBa3m66Je+jfKRblOy6IOJEUv1LPAMr5hQq6H4YR9w7Q92Ksqkg48ZUyCF1 X-Received: by 2002:a17:902:b289:: with SMTP id u9-v6mr2063759plr.189.1518184659899; Fri, 09 Feb 2018 05:57:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518184659; cv=none; d=google.com; s=arc-20160816; b=jj/9WdA6AKjgiONmkMWzLQOqXnfxqUYXFUrZeZglXdheD4jt4HkB658s8zBTXQBEaL EzbbayY9Yp8Alb3e65eP9+SDDJfuuJ666xFTgprW2Zwxh230TLVJC6cgVFXXswRQljq+ pSF186bGzpn4wZ4omuo9m5rgk2frREk4Ni6ouzgIXfwdmgKJL3GMbKQPdt5doBvREQgo vxFc4WtlvSp2+jq6gbOBhAMpcG7arXdC+IlFdLP9cuHdpXgjoDKaDwojrYZ4uy9IpfNu z1IFjB/l5zi8wvfXoaAH/M6ruEaNIXLI/hbTTeczy6/+/5eq+663yaLPDZYqhT9U3dem 597w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=PSM4xYTpH8QTJTDnqv+CmDMUCv7gRaHeyGj88ckj4xA=; b=rMKXkEdZd16L/aUH1n62k+/Fi44NuQ/wZ1wOsisY0V18Z+UIGghDRFPIXtkp+jLCrg MM37C2c3hALxkL6p97JIFxInwIQmOntdgvroQdHzz6/wHexoOq0oTYcgBaXNBSDSXwDc DzONaiMKsryjkYIGnIZitIRwiyBNOr8vHJMLSLL25idWrfOl7kXGbsHEdZqNzjGKRF1S oVSK/Rp9AuC5+rd5q+QBOuzBpe+nKbX8N/zoIy5nF7pvcsNWM4EqbW2VR1sOzIJLPD3M 1BQZzoIP5zn7Zw7gt0fOBgzq4U3ImEjy/KYdC1LR8/SaflZ90UC3a43TilfR15fVcUTd SZmQ== 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 p10si1724729pfe.287.2018.02.09.05.57.25; Fri, 09 Feb 2018 05:57:39 -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 S1753612AbeBINpS (ORCPT + 99 others); Fri, 9 Feb 2018 08:45:18 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:51766 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752879AbeBINpP (ORCPT ); Fri, 9 Feb 2018 08:45:15 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 002A910BA; Fri, 9 Feb 2018 13:45:14 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martin KaFai Lau , "David S. Miller" Subject: [PATCH 4.14 15/22] ipv6: Fix SO_REUSEPORT UDP socket with implicit sk_ipv6only Date: Fri, 9 Feb 2018 14:40:04 +0100 Message-Id: <20180209133935.189090931@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180209133934.024795822@linuxfoundation.org> References: <20180209133934.024795822@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Martin KaFai Lau [ Upstream commit 7ece54a60ee2ba7a386308cae73c790bd580589c ] If a sk_v6_rcv_saddr is !IPV6_ADDR_ANY and !IPV6_ADDR_MAPPED, it implicitly implies it is an ipv6only socket. However, in inet6_bind(), this addr_type checking and setting sk->sk_ipv6only to 1 are only done after sk->sk_prot->get_port(sk, snum) has been completed successfully. This inconsistency between sk_v6_rcv_saddr and sk_ipv6only confuses the 'get_port()'. In particular, when binding SO_REUSEPORT UDP sockets, udp_reuseport_add_sock(sk,...) is called. udp_reuseport_add_sock() checks "ipv6_only_sock(sk2) == ipv6_only_sock(sk)" before adding sk to sk2->sk_reuseport_cb. In this case, ipv6_only_sock(sk2) could be 1 while ipv6_only_sock(sk) is still 0 here. The end result is, reuseport_alloc(sk) is called instead of adding sk to the existing sk2->sk_reuseport_cb. It can be reproduced by binding two SO_REUSEPORT UDP sockets on an IPv6 address (!ANY and !MAPPED). Only one of the socket will receive packet. The fix is to set the implicit sk_ipv6only before calling get_port(). The original sk_ipv6only has to be saved such that it can be restored in case get_port() failed. The situation is similar to the inet_reset_saddr(sk) after get_port() has failed. Thanks to Calvin Owens who created an easy reproduction which leads to a fix. Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection") Signed-off-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv6/af_inet6.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/net/ipv6/af_inet6.c +++ b/net/ipv6/af_inet6.c @@ -284,6 +284,7 @@ int inet6_bind(struct socket *sock, stru struct net *net = sock_net(sk); __be32 v4addr = 0; unsigned short snum; + bool saved_ipv6only; int addr_type = 0; int err = 0; @@ -389,19 +390,21 @@ int inet6_bind(struct socket *sock, stru if (!(addr_type & IPV6_ADDR_MULTICAST)) np->saddr = addr->sin6_addr; + saved_ipv6only = sk->sk_ipv6only; + if (addr_type != IPV6_ADDR_ANY && addr_type != IPV6_ADDR_MAPPED) + sk->sk_ipv6only = 1; + /* Make sure we are allowed to bind here. */ if ((snum || !inet->bind_address_no_port) && sk->sk_prot->get_port(sk, snum)) { + sk->sk_ipv6only = saved_ipv6only; inet_reset_saddr(sk); err = -EADDRINUSE; goto out; } - if (addr_type != IPV6_ADDR_ANY) { + if (addr_type != IPV6_ADDR_ANY) sk->sk_userlocks |= SOCK_BINDADDR_LOCK; - if (addr_type != IPV6_ADDR_MAPPED) - sk->sk_ipv6only = 1; - } if (snum) sk->sk_userlocks |= SOCK_BINDPORT_LOCK; inet->inet_sport = htons(inet->inet_num);