Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2295776imc; Tue, 12 Mar 2019 10:48:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqy7GjPeM0OWd9lWYHt88mxbiiE6D9/M4u6xG10l9D47PrnYYkJsG3aIiM6q2fVvcgKILNwG X-Received: by 2002:a65:5c46:: with SMTP id v6mr35900370pgr.309.1552412928385; Tue, 12 Mar 2019 10:48:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552412928; cv=none; d=google.com; s=arc-20160816; b=J9tCElmGAbNSAyEjZ4gCCZtLZfK8fQlT6AingoP19DPHQ7ySCTbeh93k9jy69vF4Cj 8r8EvePiu0Wtgyc+N1P30YhOnpj+2oNiZBPEdv7fJm3V4m4J5SPjyexHU5Wdh+OcBGxd tKFAomqIbTQZ1a5U0tJhPeAsuJnHE9VXzBt97HwP+7U+RQBM+B4kYjI8W9LOz5HKWAk3 eOJsd5/nFGQN9xRJKuoE2cP/XebDquY9/EO8ofbXhm3DEMZqWeyDgkwBHWupGDW8OANr DCmWo0ZpsNdlxicw6GpJ85BP9yqZaWIMLHu/VQ7OOEkBPRjdxhEJF5ozf7YrWqlvKPAX FOzg== 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=0tgEYnPeJzhoMA8FKydLN001AboxCwdiycrknaGJB8M=; b=vLPsdo4Rk7nDDmRhQVffvwszAa/NudDzOpUuNpAoPvOtmlO4U4Aj4Vk1Spz5vr01ZP TAEWz0SFjI5OqsdXpkyKfZGE+rWitIIiJQIoSZ5dIxJw2grjfGVr5I3p8hYygOYq4bYH yNv1ODEII6CKmIuV2BcNbKeXYY83D35w7X/xDVSKYLk9ELOHD9v4mB+JcxfYrUEm3qHi 2zHkvKeoLkb5MzkNyWvpEcr2aVH7WLpfuwGhChW9K6O3HO5CuB9R1uhLaQm6x6zUflyr nNhTADIGUTeoe0unyuQP8X9NyX+QKxslcg5XeCIqeQNTyUGfRiwWINekXgm/h6LcO+0T 5DaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WlckK9n9; 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 x9si8222914pfm.59.2019.03.12.10.48.32; Tue, 12 Mar 2019 10:48:48 -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=WlckK9n9; 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 S1729842AbfCLRrg (ORCPT + 99 others); Tue, 12 Mar 2019 13:47:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:55170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728633AbfCLRPK (ORCPT ); Tue, 12 Mar 2019 13:15:10 -0400 Received: from localhost (unknown [104.133.8.98]) (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 5CC9F217D4; Tue, 12 Mar 2019 17:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552410909; bh=yeu5hGaVgpuGh7cfn72v+P+rc+paDZlro9hN4So6P7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WlckK9n94AXOY3SbmUnfRmOJ4nimkyxgHhgbwaE5GmSSyb5PCHIKevm64GX705Hpz tXwcM6C/83GWC8OcBcHYCxf/5Scl6FzO1RBy3CT6BjaEiL9oVa9ye11se1H8b/C3EL I7VxdVFCgyICPtLd0i/5J/aw30BGLxCVSR+cwX3c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martynas Pumputis , Florian Westphal , Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 4.19 104/149] netfilter: nf_nat: skip nat clash resolution for same-origin entries Date: Tue, 12 Mar 2019 10:08:42 -0700 Message-Id: <20190312170358.257456315@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190312170349.421581206@linuxfoundation.org> References: <20190312170349.421581206@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore 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 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit 4e35c1cb9460240e983a01745b5f29fe3a4d8e39 ] It is possible that two concurrent packets originating from the same socket of a connection-less protocol (e.g. UDP) can end up having different IP_CT_DIR_REPLY tuples which results in one of the packets being dropped. To illustrate this, consider the following simplified scenario: 1. Packet A and B are sent at the same time from two different threads by same UDP socket. No matching conntrack entry exists yet. Both packets cause allocation of a new conntrack entry. 2. get_unique_tuple gets called for A. No clashing entry found. conntrack entry for A is added to main conntrack table. 3. get_unique_tuple is called for B and will find that the reply tuple of B is already taken by A. It will allocate a new UDP source port for B to resolve the clash. 4. conntrack entry for B cannot be added to main conntrack table because its ORIGINAL direction is clashing with A and the REPLY directions of A and B are not the same anymore due to UDP source port reallocation done in step 3. This patch modifies nf_conntrack_tuple_taken so it doesn't consider colliding reply tuples if the IP_CT_DIR_ORIGINAL tuples are equal. [ Florian: simplify patch to not use .allow_clash setting and always ignore identical flows ] Signed-off-by: Martynas Pumputis Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin --- net/netfilter/nf_conntrack_core.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 277d02a8cac8..895171a2e1f1 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1007,6 +1007,22 @@ nf_conntrack_tuple_taken(const struct nf_conntrack_tuple *tuple, } if (nf_ct_key_equal(h, tuple, zone, net)) { + /* Tuple is taken already, so caller will need to find + * a new source port to use. + * + * Only exception: + * If the *original tuples* are identical, then both + * conntracks refer to the same flow. + * This is a rare situation, it can occur e.g. when + * more than one UDP packet is sent from same socket + * in different threads. + * + * Let nf_ct_resolve_clash() deal with this later. + */ + if (nf_ct_tuple_equal(&ignored_conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple, + &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple)) + continue; + NF_CT_STAT_INC_ATOMIC(net, found); rcu_read_unlock(); return 1; -- 2.19.1