frr/zebra/zebra_vrf.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

677 lines
16 KiB
C
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2016 CumulusNetworks
* Donald Sharp
*
* This file is part of Quagga
*/
#include <zebra.h>
/* for basename */
#include <libgen.h>
#include "log.h"
#include "linklist.h"
#include "command.h"
#include "memory.h"
#include "srcdest_table.h"
#include "vrf.h"
#include "vty.h"
#include "zebra/zebra_router.h"
#include "zebra/rtadv.h"
#include "zebra/debug.h"
#include "zebra/zapi_msg.h"
#include "zebra/rib.h"
#include "zebra/zebra_vrf.h"
#include "zebra/zebra_rnh.h"
#include "zebra/router-id.h"
#include "zebra/interface.h"
#include "zebra/zebra_mpls.h"
#include "zebra/zebra_vxlan.h"
#include "zebra/zebra_netns_notify.h"
#include "zebra/zebra_routemap.h"
#include "zebra/zebra_vrf_clippy.c"
#include "zebra/table_manager.h"
static void zebra_vrf_table_create(struct zebra_vrf *zvrf, afi_t afi,
safi_t safi);
static void zebra_rnhtable_node_cleanup(struct route_table *table,
struct route_node *node);
DEFINE_MTYPE_STATIC(ZEBRA, ZEBRA_VRF, "ZEBRA VRF");
DEFINE_MTYPE_STATIC(ZEBRA, OTHER_TABLE, "Other Table");
/* VRF information update. */
static void zebra_vrf_add_update(struct zebra_vrf *zvrf)
{
struct zserv *client;
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("MESSAGE: ZEBRA_VRF_ADD %s", zvrf_name(zvrf));
frr_each (zserv_client_list, &zrouter.client_list, client) {
/* Do not send unsolicited messages to synchronous clients. */
if (client->synchronous)
continue;
zsend_vrf_add(client, zvrf);
}
}
static void zebra_vrf_delete_update(struct zebra_vrf *zvrf)
{
struct zserv *client;
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("MESSAGE: ZEBRA_VRF_DELETE %s", zvrf_name(zvrf));
frr_each (zserv_client_list, &zrouter.client_list, client) {
/* Do not send unsolicited messages to synchronous clients. */
if (client->synchronous)
continue;
zsend_vrf_delete(client, zvrf);
}
}
void zebra_vrf_update_all(struct zserv *client)
{
struct vrf *vrf;
RB_FOREACH (vrf, vrf_id_head, &vrfs_by_id) {
if (vrf->vrf_id != VRF_UNKNOWN)
zsend_vrf_add(client, vrf_info_lookup(vrf->vrf_id));
}
}
/* Callback upon creating a new VRF. */
static int zebra_vrf_new(struct vrf *vrf)
{
struct zebra_vrf *zvrf;
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("VRF %s created, id %u", vrf->name, vrf->vrf_id);
zvrf = zebra_vrf_alloc(vrf);
if (!vrf_is_backend_netns())
zvrf->zns = zebra_ns_lookup(NS_DEFAULT);
else if (vrf->vrf_id == VRF_DEFAULT) {
struct ns *ns;
strlcpy(vrf->data.l.netns_name, VRF_DEFAULT_NAME, NS_NAMSIZ);
ns = ns_lookup(NS_DEFAULT);
ns->vrf_ctxt = vrf;
vrf->ns_ctxt = ns;
}
otable_init(&zvrf->other_tables);
router_id_init(zvrf);
/* Initiate Table Manager per ZNS */
table_manager_enable(zvrf);
return 0;
}
/* Callback upon enabling a VRF. */
static int zebra_vrf_enable(struct vrf *vrf)
{
struct zebra_vrf *zvrf = vrf->info;
struct route_table *table;
afi_t afi;
safi_t safi;
assert(zvrf);
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("VRF %s id %u is now active", zvrf_name(zvrf),
zvrf_id(zvrf));
if (vrf_is_backend_netns())
zvrf->zns = zebra_ns_lookup((ns_id_t)vrf->vrf_id);
else
zvrf->zns = zebra_ns_lookup(NS_DEFAULT);
rtadv_vrf_init(zvrf);
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Inform clients that the VRF is now active. This is an
* add for the clients.
*/
zebra_vrf_add_update(zvrf);
/* Allocate tables */
for (afi = AFI_IP; afi <= AFI_IP6; afi++) {
for (safi = SAFI_UNICAST; safi <= SAFI_MULTICAST; safi++)
zebra_vrf_table_create(zvrf, afi, safi);
table = route_table_init();
table->cleanup = zebra_rnhtable_node_cleanup;
zvrf->rnh_table[afi] = table;
table = route_table_init();
table->cleanup = zebra_rnhtable_node_cleanup;
zvrf->rnh_table_multicast[afi] = table;
}
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Kick off any VxLAN-EVPN processing. */
zebra_vxlan_vrf_enable(zvrf);
return 0;
}
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
/* update the VRF ID of a routing table and their routing entries */
static void zebra_vrf_disable_update_vrfid(struct zebra_vrf *zvrf, afi_t afi, safi_t safi)
{
struct rib_table_info *info;
struct route_entry *re, *nre;
struct route_node *rn, *nrn;
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
bool empty_table = true;
bool rn_delete;
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
/* Assign the table to the default VRF.
* Although the table is not technically owned by the default VRF,
* the code assumes that unassigned routing tables are
* associated with the default VRF.
*/
info = route_table_get_info(zvrf->table[afi][safi]);
info->zvrf = vrf_info_lookup(VRF_DEFAULT);
rn = route_top(zvrf->table[afi][safi]);
if (rn)
empty_table = false;
while (rn) {
if (!rn->info) {
rn = route_next(rn);
continue;
}
/* Assign the kernel route entries to the default VRF,
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
* even though they are not actually owned by it.
*
* Remove route nodes that were created by FRR daemons,
* unless they are associated with the table rather than the VRF.
* Routes associated with the VRF are not needed once the VRF is
* disabled.
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
*/
rn_delete = true;
RNODE_FOREACH_RE_SAFE (rn, re, nre) {
if (re->type == ZEBRA_ROUTE_KERNEL ||
CHECK_FLAG(re->flags, ZEBRA_FLAG_TABLEID)) {
nexthop_vrf_update(rn, re, VRF_DEFAULT);
if (CHECK_FLAG(re->flags, ZEBRA_FLAG_TABLEID))
/* reinstall routes */
rib_install_kernel(rn, re, NULL);
rn_delete = false;
} else
rib_unlink(rn, re);
}
if (rn_delete) {
nrn = route_next(rn);
zebra_node_info_cleanup(rn);
rn->info = NULL;
route_unlock_node(rn);
rn = nrn;
} else {
empty_table = false;
rn = route_next(rn);
}
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
}
if (empty_table)
zebra_router_release_table(zvrf, zvrf->table_id, afi, safi);
zvrf->table[afi][safi] = NULL;
}
/* Callback upon disabling a VRF. */
static int zebra_vrf_disable(struct vrf *vrf)
{
struct zebra_vrf *zvrf = vrf->info;
struct interface *ifp;
afi_t afi;
safi_t safi;
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
assert(zvrf);
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("VRF %s id %u is now inactive", zvrf_name(zvrf),
zvrf_id(zvrf));
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Stop any VxLAN-EVPN processing. */
zebra_vxlan_vrf_disable(zvrf);
rtadv_vrf_terminate(zvrf);
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Inform clients that the VRF is now inactive. This is a
* delete for the clients.
*/
zebra_vrf_delete_update(zvrf);
/* If asked to retain routes, there's nothing more to do. */
if (CHECK_FLAG(zvrf->flags, ZEBRA_VRF_RETAIN))
return 0;
/* Remove all routes. */
for (afi = AFI_IP; afi <= AFI_IP6; afi++) {
route_table_finish(zvrf->rnh_table[afi]);
zvrf->rnh_table[afi] = NULL;
route_table_finish(zvrf->rnh_table_multicast[afi]);
zvrf->rnh_table_multicast[afi] = NULL;
for (safi = SAFI_UNICAST; safi <= SAFI_MULTICAST; safi++)
rib_close_table(zvrf->table[afi][safi]);
}
/* Cleanup Vxlan, MPLS and PW tables. */
zebra_vxlan_cleanup_tables(zvrf);
zebra_mpls_cleanup_tables(zvrf);
zebra_pw_exit_vrf(zvrf);
/* Remove link-local IPv4 addresses created for BGP unnumbered peering.
*/
FOR_ALL_INTERFACES (vrf, ifp)
if_nbr_ipv6ll_to_ipv4ll_neigh_del_all(ifp);
/* clean-up work queues */
meta_queue_free(zrouter.mq, zvrf);
/* Cleanup (free) routing tables and NHT tables. */
for (afi = AFI_IP; afi <= AFI_IP6; afi++) {
/*
* Set the table pointer to NULL as that
* we no-longer need a copy of it, nor do we
* own this data, the zebra_router structure
* owns these tables. Once we've cleaned up the
* table, see rib_close_table above
* we no-longer need this pointer.
*/
zebra: Upon vrf deletion, actually release this data. When a vrf is deleted we need to tell the zebra_router that we have finished using the tables we are keeping track of. This will allow us to properly cleanup the data structures associated with them. This fixes this valgrind error found: ==8579== Invalid read of size 8 ==8579== at 0x430034: zvrf_id (zebra_vrf.h:167) ==8579== by 0x432366: rib_process (zebra_rib.c:1580) ==8579== by 0x432366: process_subq (zebra_rib.c:2092) ==8579== by 0x432366: meta_queue_process (zebra_rib.c:2188) ==8579== by 0x48C99FE: work_queue_run (workqueue.c:291) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Address 0x5aeb750 is 0 bytes inside a block of size 4,424 free'd ==8579== at 0x4839A0C: free (vg_replace_malloc.c:540) ==8579== by 0x438914: zebra_vrf_delete (zebra_vrf.c:279) ==8579== by 0x48C4225: vrf_delete (vrf.c:243) ==8579== by 0x48C4225: vrf_delete (vrf.c:217) ==8579== by 0x4151CE: netlink_vrf_change (if_netlink.c:364) ==8579== by 0x416810: netlink_link_change (if_netlink.c:1189) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x41C2D3: kernel_read (kernel_netlink.c:389) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Block was alloc'd at ==8579== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==8579== by 0x48A6030: qcalloc (memory.c:110) ==8579== by 0x4389EF: zebra_vrf_alloc (zebra_vrf.c:382) ==8579== by 0x438A42: zebra_vrf_new (zebra_vrf.c:93) ==8579== by 0x48C40AD: vrf_get (vrf.c:209) ==8579== by 0x415144: netlink_vrf_change (if_netlink.c:319) ==8579== by 0x415E90: netlink_interface (if_netlink.c:653) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x4163E8: interface_lookup_netlink (if_netlink.c:760) ==8579== by 0x42BB37: zebra_ns_enable (zebra_ns.c:130) ==8579== by 0x42BC5E: zebra_ns_init (zebra_ns.c:208) ==8579== by 0x4130F4: main (main.c:401) This can be found by: `ip link del <VRF DEVICE NAME>` then `ip link add <NAME> type vrf table X` again and then attempting to use the vrf. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-02-28 15:11:41 +01:00
for (safi = SAFI_UNICAST; safi <= SAFI_MULTICAST; safi++) {
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
if (!zvrf->table[afi][safi] || vrf->vrf_id == VRF_DEFAULT) {
zebra_router_release_table(zvrf, zvrf->table_id, afi, safi);
zvrf->table[afi][safi] = NULL;
continue;
}
zebra_vrf_disable_update_vrfid(zvrf, afi, safi);
zebra: Upon vrf deletion, actually release this data. When a vrf is deleted we need to tell the zebra_router that we have finished using the tables we are keeping track of. This will allow us to properly cleanup the data structures associated with them. This fixes this valgrind error found: ==8579== Invalid read of size 8 ==8579== at 0x430034: zvrf_id (zebra_vrf.h:167) ==8579== by 0x432366: rib_process (zebra_rib.c:1580) ==8579== by 0x432366: process_subq (zebra_rib.c:2092) ==8579== by 0x432366: meta_queue_process (zebra_rib.c:2188) ==8579== by 0x48C99FE: work_queue_run (workqueue.c:291) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Address 0x5aeb750 is 0 bytes inside a block of size 4,424 free'd ==8579== at 0x4839A0C: free (vg_replace_malloc.c:540) ==8579== by 0x438914: zebra_vrf_delete (zebra_vrf.c:279) ==8579== by 0x48C4225: vrf_delete (vrf.c:243) ==8579== by 0x48C4225: vrf_delete (vrf.c:217) ==8579== by 0x4151CE: netlink_vrf_change (if_netlink.c:364) ==8579== by 0x416810: netlink_link_change (if_netlink.c:1189) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x41C2D3: kernel_read (kernel_netlink.c:389) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Block was alloc'd at ==8579== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==8579== by 0x48A6030: qcalloc (memory.c:110) ==8579== by 0x4389EF: zebra_vrf_alloc (zebra_vrf.c:382) ==8579== by 0x438A42: zebra_vrf_new (zebra_vrf.c:93) ==8579== by 0x48C40AD: vrf_get (vrf.c:209) ==8579== by 0x415144: netlink_vrf_change (if_netlink.c:319) ==8579== by 0x415E90: netlink_interface (if_netlink.c:653) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x4163E8: interface_lookup_netlink (if_netlink.c:760) ==8579== by 0x42BB37: zebra_ns_enable (zebra_ns.c:130) ==8579== by 0x42BC5E: zebra_ns_init (zebra_ns.c:208) ==8579== by 0x4130F4: main (main.c:401) This can be found by: `ip link del <VRF DEVICE NAME>` then `ip link add <NAME> type vrf table X` again and then attempting to use the vrf. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-02-28 15:11:41 +01:00
}
}
return 0;
}
static int zebra_vrf_delete(struct vrf *vrf)
{
struct zebra_vrf *zvrf = vrf->info;
struct other_route_table *otable;
assert(zvrf);
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
if (IS_ZEBRA_DEBUG_EVENT)
zlog_debug("VRF %s id %u deleted", zvrf_name(zvrf),
zvrf_id(zvrf));
table_manager_disable(zvrf);
/* clean-up work queues */
meta_queue_free(zrouter.mq, zvrf);
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Free Vxlan and MPLS. */
zebra_vxlan_close_tables(zvrf);
zebra_mpls_close_tables(zvrf);
otable = otable_pop(&zvrf->other_tables);
while (otable) {
zebra_router_release_table(zvrf, otable->table_id,
otable->afi, otable->safi);
XFREE(MTYPE_OTHER_TABLE, otable);
otable = otable_pop(&zvrf->other_tables);
}
*: Handle VRF configuration when VRF gets inactivated and activated A VRF is active only when the corresponding VRF device is present in the kernel. However, when the kernel VRF device is removed, the VRF container in FRR should go away only if there is no user configuration for it. Otherwise, when the VRF device is created again so that the VRF becomes active, FRR cannot take the correct actions. Example configuration for the VRF includes static routes and EVPN L3 VNI. Note that a VRF is currently considered to be "configured" as soon as the operator has issued the "vrf <name>" command in FRR. Such a configured VRF is not deleted upon VRF device removal, it is only made inactive. A VRF that is "configured" can be deleted only upon operator action and only if the VRF has been deactivated i.e., the VRF device removed from the kernel. This is an existing restriction. To implement this change, the VRF disable and delete actions have been modified. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Ticket: CM-18553, CM-18918, CM-10139 Reviewed By: CCR-7022 Testing Done: 1. vrf and pim-vrf automation tests 2. Multiple VRF delete and readd (ifdown, ifup-with-depends) 3. FRR stop, start, restart 4. Networking restart 5. Configuration delete and readd Some of the above tests run in different sequences (manually).
2017-12-02 02:36:37 +01:00
/* Cleanup EVPN states for vrf */
zebra_vxlan_vrf_delete(zvrf);
zebra_routemap_vrf_delete(zvrf);
list_delete_all_node(zvrf->rid_all_sorted_list);
list_delete_all_node(zvrf->rid_lo_sorted_list);
list_delete_all_node(zvrf->rid6_all_sorted_list);
list_delete_all_node(zvrf->rid6_lo_sorted_list);
otable_fini(&zvrf->other_tables);
XFREE(MTYPE_ZEBRA_VRF, zvrf);
if (vrf->ns_ctxt) {
ns_delete(vrf->ns_ctxt);
vrf->ns_ctxt = NULL;
}
vrf->info = NULL;
return 0;
}
/* Lookup the routing table in a VRF based on both VRF-Id and table-id.
* NOTE: Table-id is relevant on two modes:
* - case VRF backend is default : on default VRF only
* - case VRF backend is netns : on all VRFs
*/
zebra: separate zebra_vrf_lookup_table_with_id() We were creating `other` tables in rib_del(), vty commands, and dataplane return callback via the zebra_vrf_table_with_table_id() API. Seperate the API into only a lookup, never create and added another with `get` in the name (following the standard we use in other table APIs). Then changed the rib_del(), rib_find_rn_from_ctx(), and show route summary vty command to use the lookup API instead. This was found via a crash where two different vrfs though they owned the table. On delete, one free'd all the nodes, and then the other tried to use them. It required specific timing of a VRF existing, going away, and coming back again to cause the crash. =23464== Invalid read of size 8 ==23464== at 0x179EA4: rib_dest_from_rnode (rib.h:433) ==23464== by 0x17ACB1: zebra_vrf_delete (zebra_vrf.c:253) ==23464== by 0x48F3D45: vrf_delete (vrf.c:243) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== by 0x13D8C5: sigint (main.c:172) ==23464== by 0x48DD25C: quagga_sigevent_process (sigevent.c:105) ==23464== by 0x48F0502: thread_fetch (thread.c:1417) ==23464== by 0x48AC82B: frr_run (libfrr.c:1023) ==23464== by 0x13DD02: main (main.c:483) ==23464== Address 0x5152788 is 104 bytes inside a block of size 112 free'd ==23464== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B25B8: qfree (memory.c:129) ==23464== by 0x48EA335: route_node_destroy (table.c:500) ==23464== by 0x48E967F: route_node_free (table.c:90) ==23464== by 0x48E9742: route_table_free (table.c:124) ==23464== by 0x48E9599: route_table_finish (table.c:60) ==23464== by 0x170CEA: zebra_router_free_table (zebra_router.c:165) ==23464== by 0x170DB4: zebra_router_release_table (zebra_router.c:188) ==23464== by 0x17AAD2: zebra_vrf_disable (zebra_vrf.c:222) ==23464== by 0x48F3F0C: vrf_disable (vrf.c:313) ==23464== by 0x48F3CCF: vrf_delete (vrf.c:223) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== Block was alloc'd at ==23464== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B24A2: qcalloc (memory.c:110) ==23464== by 0x48EA2FE: route_node_create (table.c:488) ==23464== by 0x48E95C7: route_node_new (table.c:66) ==23464== by 0x48E95E5: route_node_set (table.c:75) ==23464== by 0x48E9EA9: route_node_get (table.c:326) ==23464== by 0x48E1EDB: srcdest_rnode_get (srcdest_table.c:244) ==23464== by 0x16EA4B: rib_add_multipath (zebra_rib.c:2730) ==23464== by 0x1A5310: zread_route_add (zapi_msg.c:1592) ==23464== by 0x1A7B8E: zserv_handle_commands (zapi_msg.c:2579) ==23464== by 0x19D689: zserv_process_messages (zserv.c:523) ==23464== by 0x48F09F8: thread_call (thread.c:1599) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2019-11-01 20:52:47 +01:00
struct route_table *zebra_vrf_lookup_table_with_table_id(afi_t afi, safi_t safi,
vrf_id_t vrf_id,
uint32_t table_id)
{
struct zebra_vrf *zvrf = vrf_info_lookup(vrf_id);
struct other_route_table ort, *otable;
if (!zvrf)
return NULL;
if (afi >= AFI_MAX || safi >= SAFI_MAX)
return NULL;
if (table_id == zvrf->table_id)
return zebra_vrf_table(afi, safi, vrf_id);
ort.afi = afi;
ort.safi = safi;
ort.table_id = table_id;
otable = otable_find(&zvrf->other_tables, &ort);
zebra: separate zebra_vrf_lookup_table_with_id() We were creating `other` tables in rib_del(), vty commands, and dataplane return callback via the zebra_vrf_table_with_table_id() API. Seperate the API into only a lookup, never create and added another with `get` in the name (following the standard we use in other table APIs). Then changed the rib_del(), rib_find_rn_from_ctx(), and show route summary vty command to use the lookup API instead. This was found via a crash where two different vrfs though they owned the table. On delete, one free'd all the nodes, and then the other tried to use them. It required specific timing of a VRF existing, going away, and coming back again to cause the crash. =23464== Invalid read of size 8 ==23464== at 0x179EA4: rib_dest_from_rnode (rib.h:433) ==23464== by 0x17ACB1: zebra_vrf_delete (zebra_vrf.c:253) ==23464== by 0x48F3D45: vrf_delete (vrf.c:243) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== by 0x13D8C5: sigint (main.c:172) ==23464== by 0x48DD25C: quagga_sigevent_process (sigevent.c:105) ==23464== by 0x48F0502: thread_fetch (thread.c:1417) ==23464== by 0x48AC82B: frr_run (libfrr.c:1023) ==23464== by 0x13DD02: main (main.c:483) ==23464== Address 0x5152788 is 104 bytes inside a block of size 112 free'd ==23464== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B25B8: qfree (memory.c:129) ==23464== by 0x48EA335: route_node_destroy (table.c:500) ==23464== by 0x48E967F: route_node_free (table.c:90) ==23464== by 0x48E9742: route_table_free (table.c:124) ==23464== by 0x48E9599: route_table_finish (table.c:60) ==23464== by 0x170CEA: zebra_router_free_table (zebra_router.c:165) ==23464== by 0x170DB4: zebra_router_release_table (zebra_router.c:188) ==23464== by 0x17AAD2: zebra_vrf_disable (zebra_vrf.c:222) ==23464== by 0x48F3F0C: vrf_disable (vrf.c:313) ==23464== by 0x48F3CCF: vrf_delete (vrf.c:223) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== Block was alloc'd at ==23464== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B24A2: qcalloc (memory.c:110) ==23464== by 0x48EA2FE: route_node_create (table.c:488) ==23464== by 0x48E95C7: route_node_new (table.c:66) ==23464== by 0x48E95E5: route_node_set (table.c:75) ==23464== by 0x48E9EA9: route_node_get (table.c:326) ==23464== by 0x48E1EDB: srcdest_rnode_get (srcdest_table.c:244) ==23464== by 0x16EA4B: rib_add_multipath (zebra_rib.c:2730) ==23464== by 0x1A5310: zread_route_add (zapi_msg.c:1592) ==23464== by 0x1A7B8E: zserv_handle_commands (zapi_msg.c:2579) ==23464== by 0x19D689: zserv_process_messages (zserv.c:523) ==23464== by 0x48F09F8: thread_call (thread.c:1599) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2019-11-01 20:52:47 +01:00
if (otable)
return otable->table;
zebra: separate zebra_vrf_lookup_table_with_id() We were creating `other` tables in rib_del(), vty commands, and dataplane return callback via the zebra_vrf_table_with_table_id() API. Seperate the API into only a lookup, never create and added another with `get` in the name (following the standard we use in other table APIs). Then changed the rib_del(), rib_find_rn_from_ctx(), and show route summary vty command to use the lookup API instead. This was found via a crash where two different vrfs though they owned the table. On delete, one free'd all the nodes, and then the other tried to use them. It required specific timing of a VRF existing, going away, and coming back again to cause the crash. =23464== Invalid read of size 8 ==23464== at 0x179EA4: rib_dest_from_rnode (rib.h:433) ==23464== by 0x17ACB1: zebra_vrf_delete (zebra_vrf.c:253) ==23464== by 0x48F3D45: vrf_delete (vrf.c:243) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== by 0x13D8C5: sigint (main.c:172) ==23464== by 0x48DD25C: quagga_sigevent_process (sigevent.c:105) ==23464== by 0x48F0502: thread_fetch (thread.c:1417) ==23464== by 0x48AC82B: frr_run (libfrr.c:1023) ==23464== by 0x13DD02: main (main.c:483) ==23464== Address 0x5152788 is 104 bytes inside a block of size 112 free'd ==23464== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B25B8: qfree (memory.c:129) ==23464== by 0x48EA335: route_node_destroy (table.c:500) ==23464== by 0x48E967F: route_node_free (table.c:90) ==23464== by 0x48E9742: route_table_free (table.c:124) ==23464== by 0x48E9599: route_table_finish (table.c:60) ==23464== by 0x170CEA: zebra_router_free_table (zebra_router.c:165) ==23464== by 0x170DB4: zebra_router_release_table (zebra_router.c:188) ==23464== by 0x17AAD2: zebra_vrf_disable (zebra_vrf.c:222) ==23464== by 0x48F3F0C: vrf_disable (vrf.c:313) ==23464== by 0x48F3CCF: vrf_delete (vrf.c:223) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== Block was alloc'd at ==23464== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B24A2: qcalloc (memory.c:110) ==23464== by 0x48EA2FE: route_node_create (table.c:488) ==23464== by 0x48E95C7: route_node_new (table.c:66) ==23464== by 0x48E95E5: route_node_set (table.c:75) ==23464== by 0x48E9EA9: route_node_get (table.c:326) ==23464== by 0x48E1EDB: srcdest_rnode_get (srcdest_table.c:244) ==23464== by 0x16EA4B: rib_add_multipath (zebra_rib.c:2730) ==23464== by 0x1A5310: zread_route_add (zapi_msg.c:1592) ==23464== by 0x1A7B8E: zserv_handle_commands (zapi_msg.c:2579) ==23464== by 0x19D689: zserv_process_messages (zserv.c:523) ==23464== by 0x48F09F8: thread_call (thread.c:1599) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2019-11-01 20:52:47 +01:00
return NULL;
}
struct route_table *zebra_vrf_get_table_with_table_id(afi_t afi, safi_t safi,
vrf_id_t vrf_id,
uint32_t table_id)
{
struct zebra_vrf *zvrf = vrf_info_lookup(vrf_id);
struct other_route_table *otable;
struct route_table *table;
table = zebra_vrf_lookup_table_with_table_id(afi, safi, vrf_id,
table_id);
if (table)
goto done;
/* Create it as an `other` table */
table = zebra_router_get_table(zvrf, table_id, afi, safi);
otable = XCALLOC(MTYPE_OTHER_TABLE, sizeof(*otable));
otable->afi = afi;
otable->safi = safi;
otable->table_id = table_id;
otable->table = table;
otable_add(&zvrf->other_tables, otable);
zebra: separate zebra_vrf_lookup_table_with_id() We were creating `other` tables in rib_del(), vty commands, and dataplane return callback via the zebra_vrf_table_with_table_id() API. Seperate the API into only a lookup, never create and added another with `get` in the name (following the standard we use in other table APIs). Then changed the rib_del(), rib_find_rn_from_ctx(), and show route summary vty command to use the lookup API instead. This was found via a crash where two different vrfs though they owned the table. On delete, one free'd all the nodes, and then the other tried to use them. It required specific timing of a VRF existing, going away, and coming back again to cause the crash. =23464== Invalid read of size 8 ==23464== at 0x179EA4: rib_dest_from_rnode (rib.h:433) ==23464== by 0x17ACB1: zebra_vrf_delete (zebra_vrf.c:253) ==23464== by 0x48F3D45: vrf_delete (vrf.c:243) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== by 0x13D8C5: sigint (main.c:172) ==23464== by 0x48DD25C: quagga_sigevent_process (sigevent.c:105) ==23464== by 0x48F0502: thread_fetch (thread.c:1417) ==23464== by 0x48AC82B: frr_run (libfrr.c:1023) ==23464== by 0x13DD02: main (main.c:483) ==23464== Address 0x5152788 is 104 bytes inside a block of size 112 free'd ==23464== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B25B8: qfree (memory.c:129) ==23464== by 0x48EA335: route_node_destroy (table.c:500) ==23464== by 0x48E967F: route_node_free (table.c:90) ==23464== by 0x48E9742: route_table_free (table.c:124) ==23464== by 0x48E9599: route_table_finish (table.c:60) ==23464== by 0x170CEA: zebra_router_free_table (zebra_router.c:165) ==23464== by 0x170DB4: zebra_router_release_table (zebra_router.c:188) ==23464== by 0x17AAD2: zebra_vrf_disable (zebra_vrf.c:222) ==23464== by 0x48F3F0C: vrf_disable (vrf.c:313) ==23464== by 0x48F3CCF: vrf_delete (vrf.c:223) ==23464== by 0x48F4468: vrf_terminate (vrf.c:532) ==23464== Block was alloc'd at ==23464== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==23464== by 0x48B24A2: qcalloc (memory.c:110) ==23464== by 0x48EA2FE: route_node_create (table.c:488) ==23464== by 0x48E95C7: route_node_new (table.c:66) ==23464== by 0x48E95E5: route_node_set (table.c:75) ==23464== by 0x48E9EA9: route_node_get (table.c:326) ==23464== by 0x48E1EDB: srcdest_rnode_get (srcdest_table.c:244) ==23464== by 0x16EA4B: rib_add_multipath (zebra_rib.c:2730) ==23464== by 0x1A5310: zread_route_add (zapi_msg.c:1592) ==23464== by 0x1A7B8E: zserv_handle_commands (zapi_msg.c:2579) ==23464== by 0x19D689: zserv_process_messages (zserv.c:523) ==23464== by 0x48F09F8: thread_call (thread.c:1599) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2019-11-01 20:52:47 +01:00
done:
return table;
}
static void zebra_rnhtable_node_cleanup(struct route_table *table,
struct route_node *node)
{
if (node->info)
zebra_free_rnh(node->info);
}
/*
* Create a routing table for the specific AFI/SAFI in the given VRF.
*/
static void zebra_vrf_table_create(struct zebra_vrf *zvrf, afi_t afi,
safi_t safi)
{
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
vrf_id_t vrf_id = zvrf->vrf->vrf_id;
struct rib_table_info *info;
struct route_entry *re;
struct route_node *rn;
struct prefix p;
assert(!zvrf->table[afi][safi]);
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
/* Attempt to retrieve the Linux routing table using zvrf->table_id.
* If the table was created before the VRF, it will already exist.
* Otherwise, create a new table.
*/
zvrf->table[afi][safi] =
zebra_router_get_table(zvrf, zvrf->table_id, afi, safi);
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > #2 0x7fa32474d783 in route_node_get lib/table.c:283 > #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > #7 0x7fa32476689c in event_call lib/event.c:1996 > #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #9 0x55b0e4e6c32a in main zebra/main.c:526 > #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > #1 0x7fa324668d8f in qfree lib/memory.c:130 > #2 0x7fa32474c421 in route_table_free lib/table.c:126 > #3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #13 0x7fa32476689c in event_call lib/event.c:1996 > #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #15 0x55b0e4e6c32a in main zebra/main.c:526 > #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > #1 0x7fa324668c4d in qcalloc lib/memory.c:105 > #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > #3 0x7fa32474e73c in route_table_init lib/table.c:512 > #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > #12 0x7fa32476689c in event_call lib/event.c:1996 > #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > #14 0x55b0e4e6c32a in main zebra/main.c:526 > #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-11-20 16:33:55 +01:00
/* If the table existed before the VRF was created, info->zvrf was
* referring to the default VRF.
* Assign the table to the new VRF.
* Note: FRR does not allow multiple VRF interfaces to be created with the
* same table ID.
*/
info = route_table_get_info(zvrf->table[afi][safi]);
info->zvrf = zvrf;
/* If the table existed before the VRF was created, their routing entries
* was owned by the default VRF.
* Re-assign all the routing entries to the new VRF.
*/
for (rn = route_top(zvrf->table[afi][safi]); rn; rn = route_next(rn)) {
if (!rn->info)
continue;
RNODE_FOREACH_RE (rn, re)
nexthop_vrf_update(rn, re, vrf_id);
}
memset(&p, 0, sizeof(p));
p.family = afi2family(afi);
/* create a fake default route or get the existing one */
rn = srcdest_rnode_get(zvrf->table[afi][safi], &p, NULL);
if (!rn->info)
/* do not override the existing default route */
zebra_rib_create_dest(rn);
}
/* Allocate new zebra VRF. */
struct zebra_vrf *zebra_vrf_alloc(struct vrf *vrf)
{
struct zebra_vrf *zvrf;
zvrf = XCALLOC(MTYPE_ZEBRA_VRF, sizeof(struct zebra_vrf));
zvrf->vrf = vrf;
vrf->info = zvrf;
zebra_vxlan_init_tables(zvrf);
zebra_mpls_init_tables(zvrf);
zebra_pw_init_vrf(zvrf);
zvrf->table_id = rt_table_main_id;
/* by default table ID is default one */
zebra: Enable `nht resolve-via-default` by default for traditional profile Lots of questions raising regarding unresolved nht, I think it's time to relax this and make it a default ON. Here is an example list of issues when `nht resolvia-via-default` solved the problem: https://github.com/FRRouting/frr/issues/3241 https://github.com/FRRouting/frr/issues/7420 https://github.com/FRRouting/frr/issues/3474 https://github.com/FRRouting/frr/issues/5023 https://github.com/FRRouting/frr/issues/6504 https://github.com/FRRouting/frr/issues/6680 https://github.com/FRRouting/frr/issues/7049 https://github.com/FRRouting/frr/issues/7862 https://github.com/FRRouting/frr/issues/7999 https://github.com/FRRouting/frr/issues/13215 https://github.com/FRRouting/frr/issues/14098 TL;DR; The BGP session does not come up if using multihop sessions and/or the peer(nexthop) is not accessible from the RIB, but only via default route. This is even valid for iBGP, and not only for eBGP peering. Adding a static /32, /128 route for the peer would do the trick, but it's a workaround. If the route has a nexthop marked as invalid, most likely this is due to it can't be resolved from the current RIB, but only via default route. For instance, Cisco allows this by default (can't find even a knob to turn it off or I'm blind). For eBGP sessions it might be also combined with `disable-ebgp-connected-route-check`. Some people asked if this could be a default, also for instance MetalLB is adding this by default for all the configs it generates. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-08-06 19:42:47 +02:00
if (DFLT_ZEBRA_IP_NHT_RESOLVE_VIA_DEFAULT) {
zvrf->zebra_rnh_ip_default_route = true;
zvrf->zebra_rnh_ipv6_default_route = true;
}
return zvrf;
}
/*
* Pending: create an efficient table_id (in a tree/hash) based lookup)
*/
vrf_id_t zebra_vrf_lookup_by_table(uint32_t table_id, ns_id_t ns_id)
{
struct vrf *vrf;
struct zebra_vrf *zvrf;
RB_FOREACH (vrf, vrf_id_head, &vrfs_by_id) {
zvrf = vrf->info;
if (zvrf == NULL)
continue;
/* case vrf with netns : match the netnsid */
if (vrf_is_backend_netns()) {
if (ns_id == zvrf_id(zvrf))
return zvrf_id(zvrf);
} else {
/* VRF is VRF_BACKEND_VRF_LITE */
if (zvrf->table_id != table_id)
continue;
return zvrf_id(zvrf);
}
}
return VRF_DEFAULT;
}
/*
* Lookup tableid by vrfid; handle vrf-lite and vrf-netns cases
*/
int zebra_vrf_lookup_tableid(vrf_id_t vrf_id, ns_id_t ns_id)
{
struct zebra_vrf *zvrf;
/* Handle vrf-lite and vrf-netns */
if (vrf_is_backend_netns())
zvrf = vrf_info_lookup(ns_id);
else
zvrf = vrf_info_lookup(vrf_id);
if (zvrf)
return zvrf->table_id;
else
return ZEBRA_ROUTE_TABLE_UNKNOWN;
}
/* Lookup VRF by identifier. */
struct zebra_vrf *zebra_vrf_lookup_by_id(vrf_id_t vrf_id)
{
return vrf_info_lookup(vrf_id);
}
/* Lookup VRF by name. */
struct zebra_vrf *zebra_vrf_lookup_by_name(const char *name)
{
struct vrf *vrf;
if (!name)
name = VRF_DEFAULT_NAME;
vrf = vrf_lookup_by_name(name);
if (vrf)
return ((struct zebra_vrf *)vrf->info);
return NULL;
}
/* Lookup the routing table in an enabled VRF. */
struct route_table *zebra_vrf_table(afi_t afi, safi_t safi, vrf_id_t vrf_id)
{
struct zebra_vrf *zvrf = vrf_info_lookup(vrf_id);
if (!zvrf)
return NULL;
if (afi >= AFI_MAX || safi >= SAFI_MAX)
return NULL;
return zvrf->table[afi][safi];
}
/* if ns_id is different and not VRF_UNKNOWN,
* then update vrf identifier, and enable VRF
*/
static void vrf_update_vrf_id(ns_id_t ns_id, void *opaqueptr)
{
ns_id_t vrf_id = (vrf_id_t)ns_id;
vrf_id_t old_vrf_id;
struct vrf *vrf = (struct vrf *)opaqueptr;
if (!vrf)
return;
old_vrf_id = vrf->vrf_id;
if (vrf_id == vrf->vrf_id)
return;
if (vrf->vrf_id != VRF_UNKNOWN)
RB_REMOVE(vrf_id_head, &vrfs_by_id, vrf);
vrf->vrf_id = vrf_id;
RB_INSERT(vrf_id_head, &vrfs_by_id, vrf);
if (old_vrf_id == VRF_UNKNOWN)
vrf_enable(vrf);
}
int zebra_vrf_netns_handler_create(struct vty *vty, struct vrf *vrf,
char *pathname, ns_id_t ns_id,
ns_id_t internal_ns_id,
ns_id_t rel_def_ns_id)
{
struct ns *ns = NULL;
if (!vrf)
return CMD_WARNING_CONFIG_FAILED;
if (vrf->vrf_id != VRF_UNKNOWN && vrf->ns_ctxt == NULL) {
if (vty)
vty_out(vty,
"VRF %u is already configured with VRF %s\n",
vrf->vrf_id, vrf->name);
else
zlog_info("VRF %u is already configured with VRF %s",
vrf->vrf_id, vrf->name);
return CMD_WARNING_CONFIG_FAILED;
}
if (vrf->ns_ctxt != NULL) {
ns = (struct ns *)vrf->ns_ctxt;
if (!strcmp(ns->name, pathname)) {
if (vty)
vty_out(vty,
"VRF %u already configured with NETNS %s\n",
vrf->vrf_id, ns->name);
else
zlog_info(
"VRF %u already configured with NETNS %s",
vrf->vrf_id, ns->name);
return CMD_WARNING;
}
}
ns = ns_lookup_name(pathname);
if (ns && ns->vrf_ctxt) {
struct vrf *vrf2 = (struct vrf *)ns->vrf_ctxt;
if (vrf2 == vrf)
return CMD_SUCCESS;
if (vty)
vty_out(vty,
"NS %s is already configured with VRF %u(%s)\n",
ns->name, vrf2->vrf_id, vrf2->name);
else
zlog_info("NS %s is already configured with VRF %u(%s)",
ns->name, vrf2->vrf_id, vrf2->name);
return CMD_WARNING_CONFIG_FAILED;
}
ns = ns_get_created(ns, pathname, ns_id);
ns->internal_ns_id = internal_ns_id;
ns->relative_default_ns = rel_def_ns_id;
ns->vrf_ctxt = (void *)vrf;
vrf->ns_ctxt = (void *)ns;
/* update VRF netns NAME */
strlcpy(vrf->data.l.netns_name, basename(pathname), NS_NAMSIZ);
if (!ns_enable(ns, vrf_update_vrf_id)) {
if (vty)
vty_out(vty, "Can not associate NS %u with NETNS %s\n",
ns->ns_id, ns->name);
else
zlog_info("Can not associate NS %u with NETNS %s",
ns->ns_id, ns->name);
return CMD_WARNING_CONFIG_FAILED;
}
return CMD_SUCCESS;
}
/* Zebra VRF initialization. */
void zebra_vrf_init(void)
{
vrf_init(zebra_vrf_new, zebra_vrf_enable, zebra_vrf_disable,
*: rework renaming the default VRF Currently, it is possible to rename the default VRF either by passing `-o` option to zebra or by creating a file in `/var/run/netns` and binding it to `/proc/self/ns/net`. In both cases, only zebra knows about the rename and other daemons learn about it only after they connect to zebra. This is a problem, because daemons may read their config before they connect to zebra. To handle this rename after the config is read, we have some special code in every single daemon, which is not very bad but not desirable in my opinion. But things are getting worse when we need to handle this in northbound layer as we have to manually rewrite the config nodes. This approach is already hacky, but still works as every daemon handles its own NB structures. But it is completely incompatible with the central management daemon architecture we are aiming for, as mgmtd doesn't even have a connection with zebra to learn from it. And it shouldn't have it, because operational state changes should never affect configuration. To solve the problem and simplify the code, I propose to expand the `-o` option to all daemons. By using the startup option, we let daemons know about the rename before they read their configs so we don't need any special code to deal with it. There's an easy way to pass the option to all daemons by using `frr_global_options` variable. Unfortunately, the second way of renaming by creating a file in `/var/run/netns` is incompatible with the new mgmtd architecture. Theoretically, we could force daemons to read their configs only after they connect to zebra, but it means adding even more code to handle a very specific use-case. And anyway this won't work for mgmtd as it doesn't have a connection with zebra. So I had to remove this option. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2021-12-03 23:22:55 +01:00
zebra_vrf_delete);
hook_register(zserv_client_close, release_daemon_table_chunks);
}