From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D109C636CD for ; Sun, 5 Feb 2023 05:32:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229452AbjBEFb7 (ORCPT ); Sun, 5 Feb 2023 00:31:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjBEFb7 (ORCPT ); Sun, 5 Feb 2023 00:31:59 -0500 Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A0B11F5E2 for ; Sat, 4 Feb 2023 21:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1675575118; x=1707111118; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=RiQroxHsMesevYUDkYjoMfOm7jVhlZoKX6jWWO+I6PY=; b=jZHNBek/bbZB+ykvoPI6u81ozKQSUNL1vDx0bO+rGRMlnzThJeThtTd3 D+GA13l+h6wY/8VHywkxOk+ulm4KA8gChYJbYzhYUg1YL4RXGonx1b8Nm Q2SQFOqpoFLFFvcs1ssnh5WYYAqOum1y3xmYhGwIYWhErk9bUmcKEr5a3 s=; X-IronPort-AV: E=Sophos;i="5.97,274,1669075200"; d="scan'208";a="1099380297" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-pdx-2b-m6i4x-0ec33b60.us-west-2.amazon.com) ([10.25.36.214]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2023 05:31:57 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-m6i4x-0ec33b60.us-west-2.amazon.com (Postfix) with ESMTPS id 1ACD5A24AE; Sun, 5 Feb 2023 05:31:57 +0000 (UTC) Received: from EX19D046UWB004.ant.amazon.com (10.13.139.164) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Sun, 5 Feb 2023 05:31:56 +0000 Received: from dev-dsk-shaoyi-2b-b6ac9e9c.us-west-2.amazon.com (10.43.160.120) by EX19D046UWB004.ant.amazon.com (10.13.139.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.24; Sun, 5 Feb 2023 05:31:56 +0000 From: Shaoying Xu To: CC: , , , , , , Shaoying Xu Subject: [PATCH stable 5.4 2/2] ipv4: Fix incorrect route flushing when source address is deleted Date: Sun, 5 Feb 2023 05:31:00 +0000 Message-ID: <20230205053100.15903-3-shaoyi@amazon.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230205053100.15903-1-shaoyi@amazon.com> References: <20221212130920.482075438@linuxfoundation.org> <20230205053100.15903-1-shaoyi@amazon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.43.160.120] X-ClientProxiedBy: EX13D41UWB004.ant.amazon.com (10.43.161.135) To EX19D046UWB004.ant.amazon.com (10.13.139.164) Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ido Schimmel [ Upstream commit f96a3d74554df537b6db5c99c27c80e7afadc8d1 ] Cited commit added the table ID to the FIB info structure, but did not prevent structures with different table IDs from being consolidated. This can lead to routes being flushed from a VRF when an address is deleted from a different VRF. Fix by taking the table ID into account when looking for a matching FIB info. This is already done for FIB info structures backed by a nexthop object in fib_find_info_nh(). Add test cases that fail before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [FAIL] TEST: Route in default VRF not removed [ OK ] RTNETLINK answers: File exists TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [FAIL] Tests passed: 6 Tests failed: 2 And pass after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Tests passed: 8 Tests failed: 0 Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs") Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Shaoying Xu --- net/ipv4/fib_semantics.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index 908913d75847..f45b9daf62cf 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -420,6 +420,7 @@ static struct fib_info *fib_find_info(struct fib_info *nfi) nfi->fib_prefsrc == fi->fib_prefsrc && nfi->fib_priority == fi->fib_priority && nfi->fib_type == fi->fib_type && + nfi->fib_tb_id == fi->fib_tb_id && memcmp(nfi->fib_metrics, fi->fib_metrics, sizeof(u32) * RTAX_MAX) == 0 && !((nfi->fib_flags ^ fi->fib_flags) & ~RTNH_COMPARE_MASK) && -- 2.38.1