New config parameter (msd) in pcc configuration #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merged

rampxxxx merged 1 commit into pathd-pcep-release-20.2 from pathd-pcep-release-20.2-msd-fix

May 13, 2020

Member

rampxxxx commented May 11, 2020 •

edited

Loading

Now MSD (Maximum SID Depth) is not sended to remote PCE in open message, fix that taking value from configuration even the ideally feature is getting from isis (which should be a future fix).

Both PCE tested (Cisco and ODL) requires flag sr-draft07 in pce configuration for the MSD value to be processed.

It's been tested

In cisco it's been checked with show pce ipv4 peer detail
In ODL with karaf log (log:set DEBUG)

rampxxxx assigned sylane

rampxxxx requested a review from bradyallenjohnson

May 11, 2020 13:22

bradyallenjohnson requested a review from sylane

May 12, 2020 09:35

bradyallenjohnson approved these changes

View reviewed changes

rampxxxx force-pushed the pathd-pcep-release-20.2-msd-fix branch from c5f6d15 to 1a21f74 Compare

May 13, 2020 06:41

Collaborator

sylane commented May 13, 2020

From what I could see, Cisco is understanding the "Aggregate Bandwidth Consumption" metric as the "Max SID Depth", and this should be fixed in some ways through a special profile for Cisco or something similar. This MSD is somehow different, I am curious about the interaction between the two. With this PR, does the Cisco PCE still requiring the metrics ?

sylane requested changes

View reviewed changes

Collaborator

sylane left a comment

The config writing is missing, see function pcep_cli_pcc_config_write

Member Author

rampxxxx commented May 13, 2020

There are two levels of msd one per node (pcc) and another per lsp.
The "abc" metric is used by cisco as the lsp msd (which I think is a bug).
This fix has been tested in ODL PCE and CISCO PCE and both read the global msd properly

rampxxxx force-pushed the pathd-pcep-release-20.2-msd-fix branch from 1a21f74 to 48ab053 Compare

May 13, 2020 10:25


          New config parameter (msd) in pcc configuration

84b63ba

Signed-off-by: Javier Garcia <javier.garcia@voltanet.io>

rampxxxx force-pushed the pathd-pcep-release-20.2-msd-fix branch from 48ab053 to 84b63ba Compare

May 13, 2020 10:32

rampxxxx requested a review from sylane

May 13, 2020 11:10

sylane approved these changes

View reviewed changes

rampxxxx merged commit 9b79197 into pathd-pcep-release-20.2

sylane deleted the pathd-pcep-release-20.2-msd-fix branch

July 22, 2020 09:44

mwinter-osr pushed a commit that referenced this pull request


          zebra: fix use of freed es during zebra shutdown

e378f50

This problem was reported by the sanitizer -
=================================================================
==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138
READ of size 8 at 0x60d0000115c8 thread T0
    #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041
    #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234
    #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205
    #3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229
    #4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541
    #5 0x55cb9ceba0af in sigint zebra/main.c:176
    #6 0x55cb9ceba0af in sigint zebra/main.c:130
    #7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103
    #8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396
    #9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092
    #10 0x55cb9ce931d8 in main zebra/main.c:488
    #11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09)
=================================================================

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: fix use of freed es during zebra shutdown

51c56f8

This problem was reported by the sanitizer -
=================================================================
==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138
READ of size 8 at 0x60d0000115c8 thread T0
    #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041
    #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234
    #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205
    #3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229
    #4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541
    #5 0x55cb9ceba0af in sigint zebra/main.c:176
    #6 0x55cb9ceba0af in sigint zebra/main.c:130
    #7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103
    #8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396
    #9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092
    #10 0x55cb9ce931d8 in main zebra/main.c:488
    #11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09)
=================================================================

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: Fix use after free in debug path

7e26b9d

When zebra is running with debugs turned on there
is a use after free reported by the address sanitizer:

2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing
2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3
=================================================================
==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8
READ of size 8 at 0x608000011d28 thread T0
    #0 0x555555705ab5 in re_list_const_first zebra/rib.h:222
    #1 0x555555705b54 in re_list_first zebra/rib.h:222
    #2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248
    #3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #6 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #8 0x55555561a578 in main zebra/main.c:455
    #9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
    #10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429)
0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78)
freed by thread T0 here:
    #0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
    #1 0x7ffff739ccad in qfree lib/memory.c:129
    #2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746
    #3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240
    #4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245
    #5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #8 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #10 0x55555561a578 in main zebra/main.c:455
    #11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
    #0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
    #1 0x7ffff739cb98 in qcalloc lib/memory.c:110
    #2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515
    #3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576
    #4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607
    #5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012
    #6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049
    #7 0x55555571788b in rib_add zebra/zebra_rib.c:3327
    #8 0x5555555e584a in connected_up zebra/connected.c:254
    #9 0x5555555e42ff in connected_announce zebra/connected.c:94
    #10 0x5555555e4fd3 in connected_update zebra/connected.c:195
    #11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340
    #12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213
    #13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350
    #14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941
    #15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402
    #16 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #18 0x55555561a578 in main zebra/main.c:455
    #19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first

This is happening because we are using the dest pointer after a call into
rib_gc_dest.  In process_subq_route, we call rib_process() and if the
dest is deleted dest pointer is now garbage.  We must reload the
dest pointer in this case.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: Fix use after free in debug path

947097e

When zebra is running with debugs turned on there
is a use after free reported by the address sanitizer:

2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing
2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3
=================================================================
==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8
READ of size 8 at 0x608000011d28 thread T0
    #0 0x555555705ab5 in re_list_const_first zebra/rib.h:222
    #1 0x555555705b54 in re_list_first zebra/rib.h:222
    #2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248
    #3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #6 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #8 0x55555561a578 in main zebra/main.c:455
    #9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
    #10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429)
0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78)
freed by thread T0 here:
    #0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
    #1 0x7ffff739ccad in qfree lib/memory.c:129
    #2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746
    #3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240
    #4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245
    #5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #8 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #10 0x55555561a578 in main zebra/main.c:455
    #11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
    #0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
    #1 0x7ffff739cb98 in qcalloc lib/memory.c:110
    #2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515
    #3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576
    #4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607
    #5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012
    #6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049
    #7 0x55555571788b in rib_add zebra/zebra_rib.c:3327
    #8 0x5555555e584a in connected_up zebra/connected.c:254
    #9 0x5555555e42ff in connected_announce zebra/connected.c:94
    #10 0x5555555e4fd3 in connected_update zebra/connected.c:195
    #11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340
    #12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213
    #13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350
    #14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941
    #15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402
    #16 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #18 0x55555561a578 in main zebra/main.c:455
    #19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first

This is happening because we are using the dest pointer after a call into
rib_gc_dest.  In process_subq_route, we call rib_process() and if the
dest is deleted dest pointer is now garbage.  We must reload the
dest pointer in this case.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          ldpd: Clean up use after free in shutdown

f568f87

Config data was being freed just prior to it
being used for cleanup in shutdown.  Prevent this
from happening.

./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-=================================================================
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142:==2274142==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d00000c880 at pc 0x0000004d94d1 bp 0x7ffd46637810 sp 0
x7ffd46637808
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-READ of size 4 at 0x61d00000c880 thread T0
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #0 0x4d94d0 in ldp_rtr_id_get /home/sharpd/frr8/ldpd/ldpd.c:983:20
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #1 0x56ff92 in gen_ldp_hdr /home/sharpd/frr8/ldpd/packet.c:47:19
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #2 0x56a4b0 in send_notification_full /home/sharpd/frr8/ldpd/notification.c:49:9
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #3 0x56c4b3 in send_notification /home/sharpd/frr8/ldpd/notification.c:117:2
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #4 0x573fb7 in session_shutdown /home/sharpd/frr8/ldpd/packet.c:666:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #5 0x4e2ef1 in adj_del /home/sharpd/frr8/ldpd/adjacency.c:145:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #6 0x55d425 in ldpe_shutdown /home/sharpd/frr8/ldpd/ldpe.c:231:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #7 0x55a9a0 in ldpe_dispatch_main /home/sharpd/frr8/ldpd/ldpe.c:631:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #8 0x7f0c00c035e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #9 0x5586f2 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:138:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #10 0x4d46d2 in main /home/sharpd/frr8/ldpd/ldpd.c:339:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #11 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #12 0x429cb9 in _start (/usr/lib/frr/ldpd+0x429cb9)
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-0x61d00000c880 is located 0 bytes inside of 2008-byte region [0x61d00000c880,0x61d00000d058)
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-freed by thread T0 here:
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #0 0x4a3aad in free (/usr/lib/frr/ldpd+0x4a3aad)
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #1 0x4de6c8 in config_clear /home/sharpd/frr8/ldpd/ldpd.c:2001:2
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #2 0x55d12d in ldpe_shutdown /home/sharpd/frr8/ldpd/ldpe.c:211:2
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #3 0x55a9a0 in ldpe_dispatch_main /home/sharpd/frr8/ldpd/ldpe.c:631:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #4 0x7f0c00c035e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #5 0x5586f2 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:138:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #6 0x4d46d2 in main /home/sharpd/frr8/ldpd/ldpd.c:339:3
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #7 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-previously allocated by thread T0 here:
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #0 0x4a3ea2 in calloc (/usr/lib/frr/ldpd+0x4a3ea2)
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #1 0x4d6146 in config_new_empty /home/sharpd/frr8/ldpd/ldpd.c:1967:10
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #2 0x558678 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:134:11
--
./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-    #4 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: Cleanup use after free in shutdown

c2270bf

On shutdown a use after free was being seen of a route table.
Basically the pointer was kept around and resent for cleanup.
Probably something needs to be unwound to make this better
in the future.  Just cleaning up the use after free.

./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-=================================================================
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929:==911929==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000127a00 at pc 0x7fb9ad546f5b bp 0x7ffc3cff0330 sp 0x7ffc3
cff0328
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-READ of size 8 at 0x606000127a00 thread T0
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #0 0x7fb9ad546f5a in route_table_free /home/sharpd/frr8/lib/table.c:103:13
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #1 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #2 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #3 0x6b9158 in zebra_ns_disabled /home/sharpd/frr8/zebra/zebra_ns.c:116:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #4 0x7fb9ad43f0f5 in ns_disable_internal /home/sharpd/frr8/lib/netns_linux.c:273:4
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #5 0x7fb9ad43e634 in ns_disable /home/sharpd/frr8/lib/netns_linux.c:368:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #6 0x7fb9ad43e251 in ns_delete /home/sharpd/frr8/lib/netns_linux.c:330:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #7 0x7fb9ad43fbb3 in ns_terminate /home/sharpd/frr8/lib/netns_linux.c:524:3
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #8 0x54f8de in zebra_finalize /home/sharpd/frr8/zebra/main.c:232:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #9 0x7fb9ad5655e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #10 0x7fb9ad3d3343 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #12 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #13 0x443549 in _start (/usr/lib/frr/zebra+0x443549)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-0x606000127a00 is located 0 bytes inside of 56-byte region [0x606000127a00,0x606000127a38)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-freed by thread T0 here:
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #0 0x4bd33d in free (/usr/lib/frr/zebra+0x4bd33d)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #1 0x7fb9ad42cc80 in qfree /home/sharpd/frr8/lib/memory.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #2 0x7fb9ad547305 in route_table_free /home/sharpd/frr8/lib/table.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #3 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #4 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #5 0x6b9692 in zebra_ns_early_shutdown /home/sharpd/frr8/zebra/zebra_ns.c:164:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #6 0x7fb9ad43f228 in ns_walk_func /home/sharpd/frr8/lib/netns_linux.c:386:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #7 0x55014f in sigint /home/sharpd/frr8/zebra/main.c:194:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #8 0x7fb9ad50db99 in frr_sigevent_process /home/sharpd/frr8/lib/sigevent.c:130:6
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #9 0x7fb9ad560d07 in thread_fetch /home/sharpd/frr8/lib/thread.c:1775:4
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #10 0x7fb9ad3d332d in frr_run /home/sharpd/frr8/lib/libfrr.c:1197:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2
--
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-    #7 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: Prevent use after free of peer structure

b242e73

When changing the peers sockunion structure the bgp->peer
list was not being updated properly.  Since the peer's su
is being used for a sorted insert then the change of it requires
that the value be pulled out of the bgp->peer list and then
put back into as well.

Additionally ensure that the hash is always released on peer
deletion.

Lead to this from this decode in a address sanitizer run.

=================================================================
==30778==ERROR: AddressSanitizer: heap-use-after-free on address 0x62a0000d8440 at pc 0x7f48c9c5c547 bp 0x7ffcba272cb0 sp 0x7ffcba272ca8
READ of size 2 at 0x62a0000d8440 thread T0
    #0 0x7f48c9c5c546 in sockunion_same lib/sockunion.c:425
    #1 0x55cfefe3000f in peer_hash_same bgpd/bgpd.c:890
    #2 0x7f48c9bde039 in hash_release lib/hash.c:209
    #3 0x55cfefe3373f in bgp_peer_conf_if_to_su_update bgpd/bgpd.c:1541
    #4 0x55cfefd0be7a in bgp_stop bgpd/bgp_fsm.c:1631
    #5 0x55cfefe4028f in peer_delete bgpd/bgpd.c:2362
    #6 0x55cfefdd5e97 in no_neighbor_interface_config bgpd/bgp_vty.c:4267
    #7 0x7f48c9b9d160 in cmd_execute_command_real lib/command.c:949
    #8 0x7f48c9ba1112 in cmd_execute_command lib/command.c:1009
    #9 0x7f48c9ba1573 in cmd_execute lib/command.c:1162
    #10 0x7f48c9c87402 in vty_command lib/vty.c:526
    #11 0x7f48c9c87832 in vty_execute lib/vty.c:1291
    #12 0x7f48c9c8e741 in vtysh_read lib/vty.c:2130
    #13 0x7f48c9c7a66d in thread_call lib/thread.c:1585
    #14 0x7f48c9bf64e7 in frr_run lib/libfrr.c:1123
    #15 0x55cfefc75a15 in main bgpd/bgp_main.c:540
    #16 0x7f48c96b009a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #17 0x55cfefc787f9 in _start (/usr/lib/frr/bgpd+0xe27f9)

0x62a0000d8440 is located 576 bytes inside of 23376-byte region [0x62a0000d8200,0x62a0000ddd50)
freed by thread T0 here:
    #0 0x7f48c9eb9fb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
    #1 0x55cfefe3fe42 in peer_free bgpd/bgpd.c:1113
    #2 0x55cfefe3fe42 in peer_unlock_with_caller bgpd/bgpd.c:1144
    #3 0x55cfefe4092e in peer_delete bgpd/bgpd.c:2457
    #4 0x55cfefdd5e97 in no_neighbor_interface_config bgpd/bgp_vty.c:4267
    #5 0x7f48c9b9d160 in cmd_execute_command_real lib/command.c:949
    #6 0x7f48c9ba1112 in cmd_execute_command lib/command.c:1009
    #7 0x7f48c9ba1573 in cmd_execute lib/command.c:1162
    #8 0x7f48c9c87402 in vty_command lib/vty.c:526
    #9 0x7f48c9c87832 in vty_execute lib/vty.c:1291
    #10 0x7f48c9c8e741 in vtysh_read lib/vty.c:2130
    #11 0x7f48c9c7a66d in thread_call lib/thread.c:1585
    #12 0x7f48c9bf64e7 in frr_run lib/libfrr.c:1123
    #13 0x55cfefc75a15 in main bgpd/bgp_main.c:540
    #14 0x7f48c96b009a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: cleanup macip_path_list for remote macip

889360d

ASAN reported the following memleak:
```
Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x4d4342 in calloc (/usr/lib/frr/bgpd+0x4d4342)
    #1 0xbc3d68 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27
    #2 0xb869f7 in list_new /home/sharpd/frr8/lib/linklist.c:64:9
    #3 0x5a38bc in bgp_evpn_remote_ip_hash_alloc /home/sharpd/frr8/bgpd/bgp_evpn.c:6789:24
    #4 0xb358d3 in hash_get /home/sharpd/frr8/lib/hash.c:162:13
    #5 0x593d39 in bgp_evpn_remote_ip_hash_add /home/sharpd/frr8/bgpd/bgp_evpn.c:6881:7
    #6 0x59dbbd in install_evpn_route_entry_in_vni_common /home/sharpd/frr8/bgpd/bgp_evpn.c:3049:2
    #7 0x59cfe0 in install_evpn_route_entry_in_vni_ip /home/sharpd/frr8/bgpd/bgp_evpn.c:3126:8
    #8 0x59c6f0 in install_evpn_route_entry /home/sharpd/frr8/bgpd/bgp_evpn.c:3318:8
    #9 0x59bb52 in install_uninstall_route_in_vnis /home/sharpd/frr8/bgpd/bgp_evpn.c:3888:10
    #10 0x59b6d2 in bgp_evpn_install_uninstall_table /home/sharpd/frr8/bgpd/bgp_evpn.c:4019:5
    #11 0x578857 in install_uninstall_evpn_route /home/sharpd/frr8/bgpd/bgp_evpn.c:4051:9
    #12 0x58ada6 in bgp_evpn_import_route /home/sharpd/frr8/bgpd/bgp_evpn.c:6049:9
    #13 0x713794 in bgp_update /home/sharpd/frr8/bgpd/bgp_route.c:4842:3
    #14 0x583fa0 in process_type2_route /home/sharpd/frr8/bgpd/bgp_evpn.c:4518:9
    #15 0x5824ba in bgp_nlri_parse_evpn /home/sharpd/frr8/bgpd/bgp_evpn.c:5732:8
    #16 0x6ae6a2 in bgp_nlri_parse /home/sharpd/frr8/bgpd/bgp_packet.c:363:10
    #17 0x6be6fa in bgp_update_receive /home/sharpd/frr8/bgpd/bgp_packet.c:2020:15
    #18 0x6b7433 in bgp_process_packet /home/sharpd/frr8/bgpd/bgp_packet.c:2929:11
    #19 0xd00146 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
```

The list itself was not being cleaned up when the final list entry was
removed, so make sure we do that instead of leaking memory.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: Fix nexthop group memory leak

478c62e

Address Sanitizer found this:

=================================================================
==418623==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 4 object(s) allocated from:
    #0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732)
    #1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27
    #2 0x7feaeaba40f4 in nexthop_group_new /home/sharpd/frr8/lib/nexthop_group.c:270:9
    #3 0x56859b in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:950:9
    #4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2
    #5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10
    #6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12
    #7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2
    #8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
    #9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
    #10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2
    #11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16

Indirect leak of 576 byte(s) in 4 object(s) allocated from:
    #0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732)
    #1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27
    #2 0x7feaeab9b3f8 in nexthop_new /home/sharpd/frr8/lib/nexthop.c:373:7
    #3 0x56875e in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:960:15
    #4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2
    #5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10
    #6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12
    #7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2
    #8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
    #9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
    #10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2
    #11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: 704 byte(s) leaked in 8 allocation(s).

Fix this!

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix show bgp all with evpn

0adc5bb

Fix crash on "show bgp all" when BGP EVPN is set.

> #0  raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007fdfe03cf53c in core_handler (signo=11, siginfo=0x7ffdebbffe30, context=0x7ffdebbffd00) at lib/sigevent.c:261
> #2  <signal handler called>
> #3  0x00000000004d4fec in bgp_attr_get_community (attr=0x41) at bgpd/bgp_attr.h:553
> #4  0x00000000004eee84 in bgp_show_table (vty=0x1a790d0, bgp=0x19d0a00, safi=SAFI_EVPN, table=0x19f6010, type=bgp_show_type_normal, output_arg=0x0, rd=0x0, is_last=1, output_cum=0x0,
>     total_cum=0x0, json_header_depth=0x7ffdebc00bf8, show_flags=4, rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11329
> #5  0x00000000004f7765 in bgp_show (vty=0x1a790d0, bgp=0x19d0a00, afi=AFI_L2VPN, safi=SAFI_EVPN, type=bgp_show_type_normal, output_arg=0x0, show_flags=4,
>     rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11814
> #6  0x00000000004fb53b in show_ip_bgp_magic (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050, viewvrfname=0x0, all=0x1395390 "all", aa_nn=0x0, community_list=0,
>     community_list_str=0x0, community_list_name=0x0, as_path_filter_name=0x0, prefix_list=0x0, accesslist_name=0x0, rmap_name=0x0, version=0, version_str=0x0, alias_name=0x0,
>     orr_group_name=0x0, detail_routes=0x0, uj=0x0, detail_json=0x0, wide=0x0) at bgpd/bgp_route.c:13040
> #7  0x00000000004fa322 in show_ip_bgp (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050) at ./bgpd/bgp_route_clippy.c:519
> #8  0x00007fdfe033ccc8 in cmd_execute_command_real (vline=0x19c9300, filter=FILTER_RELAXED, vty=0x1a790d0, cmd=0x0, up_level=0) at lib/command.c:996
> #9  0x00007fdfe033c739 in cmd_execute_command (vline=0x19c9300, vty=0x1a790d0, cmd=0x0, vtysh=0) at lib/command.c:1056
> #10 0x00007fdfe033cdf5 in cmd_execute (vty=0x1a790d0, cmd=0x19c9eb0 "show bgp all", matched=0x0, vtysh=0) at lib/command.c:1223
> #11 0x00007fdfe03f65c6 in vty_command (vty=0x1a790d0, buf=0x19c9eb0 "show bgp all") at lib/vty.c:486
> #12 0x00007fdfe03f603b in vty_execute (vty=0x1a790d0) at lib/vty.c:1249
> #13 0x00007fdfe03f533b in vtysh_read (thread=0x7ffdebc03838) at lib/vty.c:2148
> #14 0x00007fdfe03e815d in thread_call (thread=0x7ffdebc03838) at lib/thread.c:2006
> #15 0x00007fdfe0379b54 in frr_run (master=0x1246880) at lib/libfrr.c:1198
> #16 0x000000000042b2a8 in main (argc=7, argv=0x7ffdebc03af8) at bgpd/bgp_main.c:520

Link: FRRouting#12576
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

ton31337 added a commit that referenced this pull request


          test

2c5c011

```
==58960==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040000707a8 at pc 0x55c24bbcd023 bp 0x7ffdb042d050 sp 0x7ffdb042d040
READ of size 8 at 0x6040000707a8 thread T0
    #0 0x55c24bbcd022 in aspath_key_make bgpd/bgp_aspath.c:2070
    #1 0x55c24b8f1140 in attrhash_key_make bgpd/bgp_attr.c:777
    #2 0x7f52322e66c9 in hash_release lib/hash.c:220
    #3 0x55c24b8f6017 in bgp_attr_unintern bgpd/bgp_attr.c:1271
    #4 0x55c24ba0acaa in bgp_path_info_free_with_caller bgpd/bgp_route.c:283
    #5 0x55c24ba0a7de in bgp_path_info_unlock bgpd/bgp_route.c:309
    #6 0x55c24ba0af6d in bgp_path_info_reap bgpd/bgp_route.c:426
    #7 0x55c24ba17b9a in bgp_process_main_one bgpd/bgp_route.c:3333
    #8 0x55c24ba18a1d in bgp_process_wq bgpd/bgp_route.c:3425
    #9 0x7f52323c2cd5 in work_queue_run lib/workqueue.c:282
    #10 0x7f52323aab92 in thread_call lib/thread.c:2006
    #11 0x7f5232300dc7 in frr_run lib/libfrr.c:1198
    #12 0x55c24b8ea792 in main bgpd/bgp_main.c:520
    #13 0x7f5231c3a082 in __libc_start_main ../csu/libc-start.c:308
    #14 0x55c24b8ef0bd in _start (/usr/lib/frr/bgpd+0x2c90bd)

0x6040000707a8 is located 24 bytes inside of 40-byte region [0x604000070790,0x6040000707b8)
freed by thread T0 here:
    #0 0x7f52326e740f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
    #1 0x55c24bbcc36f in aspath_unintern bgpd/bgp_aspath.c:345
    #2 0x55c24b8f56f2 in bgp_attr_unintern_sub bgpd/bgp_attr.c:1204
    #3 0x55c24b8f6049 in bgp_attr_unintern bgpd/bgp_attr.c:1277
    #4 0x55c24bbc9c1a in bgp_adj_in_remove bgpd/bgp_advertise.c:208
    #5 0x55c24ba0b0d4 in bgp_clear_route_table bgpd/bgp_route.c:5553
    #6 0x55c24ba1ba57 in bgp_clear_route bgpd/bgp_route.c:5612
    #7 0x55c24ba1bedf in bgp_clear_route_all bgpd/bgp_route.c:5634
    #8 0x55c24b99c762 in bgp_fsm_change_status bgpd/bgp_fsm.c:1288
    #9 0x55c24b9a163d in bgp_event_update bgpd/bgp_fsm.c:2639
    #10 0x55c24b9a176b in bgp_event bgpd/bgp_fsm.c:2591
    #11 0x7f52323aab92 in thread_call lib/thread.c:2006
    #12 0x7f5232300dc7 in frr_run lib/libfrr.c:1198
    #13 0x55c24b8ea792 in main bgpd/bgp_main.c:520
    #14 0x7f5231c3a082 in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
    #0 0x7f52326e7808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f523231e209 in qmalloc lib/memory.c:111
    #2 0x55c24bbcb889 in aspath_hash_alloc bgpd/bgp_aspath.c:728
    #3 0x7f52322e5f07 in hash_get lib/hash.c:162
    #4 0x55c24bbcd63b in aspath_parse bgpd/bgp_aspath.c:862
    #5 0x55c24b8fd48c in bgp_attr_aspath bgpd/bgp_attr.c:1613
    #6 0x55c24b8fd48c in bgp_attr_parse bgpd/bgp_attr.c:3656
    #7 0x55c24b9e2f22 in bgp_update_receive bgpd/bgp_packet.c:1952
    #8 0x55c24b9e9a3f in bgp_process_packet bgpd/bgp_packet.c:2940
    #9 0x7f52323aab92 in thread_call lib/thread.c:2006
    #10 0x7f5232300dc7 in frr_run lib/libfrr.c:1198
    #11 0x55c24b8ea792 in main bgpd/bgp_main.c:520
    #12 0x7f5231c3a082 in __libc_start_main ../csu/libc-start.c:308
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 added a commit that referenced this pull request


          bgpd: Intern attributes before putting into rib-out

29a9aae

After we call subgroup_announce_check(), we leave communities, large-communities
that are modified by route-maps uninterned, and here we have a memory leak.

```
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Direct leak of 80 byte(s) in 2 object(s) allocated from:
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #0 0x7f0858d90037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #1 0x7f08589b15b2 in qcalloc lib/memory.c:105
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #2 0x561f5c4e08d2 in lcommunity_new bgpd/bgp_lcommunity.c:28
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #3 0x561f5c4e11d9 in lcommunity_dup bgpd/bgp_lcommunity.c:141
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #4 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #5 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #6 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #7 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #8 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #9 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #10 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #11 0x7f0858a76e4e in thread_call lib/thread.c:1991
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #12 0x7f0858974c24 in frr_run lib/libfrr.c:1185
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #13 0x561f5c3e955d in main bgpd/bgp_main.c:505
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #14 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Indirect leak of 144 byte(s) in 2 object(s) allocated from:
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #0 0x7f0858d8fe8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #1 0x7f08589b1579 in qmalloc lib/memory.c:100
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #2 0x561f5c4e1282 in lcommunity_dup bgpd/bgp_lcommunity.c:144
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #3 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #4 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #5 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #6 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #7 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #8 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #9 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #10 0x7f0858a76e4e in thread_call lib/thread.c:1991
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #11 0x7f0858974c24 in frr_run lib/libfrr.c:1185
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #12 0x561f5c3e955d in main bgpd/bgp_main.c:505
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-    #13 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-
./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-SUMMARY: AddressSanitizer: 224 byte(s) leaked in 4 allocation(s).
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

NetDEF-CI pushed a commit that referenced this pull request


          staticd: Tell bfd that we are shutting down

7a185ac

Prevent a use after free and tell the bfd subsystem
we are shutting down in staticd.

./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460:==2264460==ERROR: AddressSanitizer: heap-use-after-free on address 0x61f000004698 at pc 0x7f65d1eb11b2 bp 0x7ffdbface490 sp 0x7ffdbface488
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-READ of size 4 at 0x61f000004698 thread T0
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #0 0x7f65d1eb11b1 in zclient_bfd_command lib/bfd.c:307
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #1 0x7f65d1eb20f5 in _bfd_sess_send lib/bfd.c:507
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #2 0x7f65d20510aa in thread_call lib/thread.c:1989
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #3 0x7f65d2051f0a in _thread_execute lib/thread.c:2081
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #4 0x7f65d1eb271b in _bfd_sess_remove lib/bfd.c:544
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #5 0x7f65d1eb278d in bfd_sess_free lib/bfd.c:553
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #6 0x7f65d1eb5400 in bfd_protocol_integration_finish lib/bfd.c:1029
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #7 0x7f65d1f42f77 in hook_call_frr_fini lib/libfrr.c:41
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #8 0x7f65d1f494a1 in frr_fini lib/libfrr.c:1199
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #9 0x563b7abefd76 in sigint staticd/static_main.c:70
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #10 0x7f65d200ef91 in frr_sigevent_process lib/sigevent.c:115
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #11 0x7f65d204fac6 in thread_fetch lib/thread.c:1758
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #12 0x7f65d1f49377 in frr_run lib/libfrr.c:1184
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #13 0x563b7abefed1 in main staticd/static_main.c:160
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #14 0x7f65d1b92d09 in __libc_start_main ../csu/libc-start.c:308
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #15 0x563b7abefa99 in _start (/usr/lib/frr/staticd+0x15a99)
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

ton31337 pushed a commit that referenced this pull request


          staticd: Tell bfd that we are shutting down

a46e6f8

Prevent a use after free and tell the bfd subsystem
we are shutting down in staticd.

./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460:==2264460==ERROR: AddressSanitizer: heap-use-after-free on address 0x61f000004698 at pc 0x7f65d1eb11b2 bp 0x7ffdbface490 sp 0x7ffdbface488
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-READ of size 4 at 0x61f000004698 thread T0
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #0 0x7f65d1eb11b1 in zclient_bfd_command lib/bfd.c:307
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #1 0x7f65d1eb20f5 in _bfd_sess_send lib/bfd.c:507
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #2 0x7f65d20510aa in thread_call lib/thread.c:1989
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #3 0x7f65d2051f0a in _thread_execute lib/thread.c:2081
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #4 0x7f65d1eb271b in _bfd_sess_remove lib/bfd.c:544
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #5 0x7f65d1eb278d in bfd_sess_free lib/bfd.c:553
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #6 0x7f65d1eb5400 in bfd_protocol_integration_finish lib/bfd.c:1029
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #7 0x7f65d1f42f77 in hook_call_frr_fini lib/libfrr.c:41
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #8 0x7f65d1f494a1 in frr_fini lib/libfrr.c:1199
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #9 0x563b7abefd76 in sigint staticd/static_main.c:70
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #10 0x7f65d200ef91 in frr_sigevent_process lib/sigevent.c:115
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #11 0x7f65d204fac6 in thread_fetch lib/thread.c:1758
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #12 0x7f65d1f49377 in frr_run lib/libfrr.c:1184
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #13 0x563b7abefed1 in main staticd/static_main.c:160
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #14 0x7f65d1b92d09 in __libc_start_main ../csu/libc-start.c:308
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-    #15 0x563b7abefa99 in _start (/usr/lib/frr/staticd+0x15a99)
./bfd_topo3.test_bfd_topo3/r4.staticd.asan.2264460-

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7a185ac)

ton31337 pushed a commit that referenced this pull request


          bgpd : aggregate-address memory leak fix

7a70d99

Memory leaks are observed in the cleanup code. When “no router bgp" is executed,
cleanup in that flow for aggregate-address command is not taken care.

fixes the below leak:
    --
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #4 0x562bf42f1e55 in aggregate_addressv6_magic bgpd/bgp_route.c:8592
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #5 0x562bf42be3f5 in aggregate_addressv6 bgpd/bgp_route_clippy.c:341
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #12 0x7f163e593f16 in event_call lib/event.c:1995
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #14 0x562bf414e58d in main bgpd/bgp_main.c:505
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #4 0x562bf42f1cde in aggregate_addressv4_magic bgpd/bgp_route.c:8543
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #5 0x562bf42bd258 in aggregate_addressv4 bgpd/bgp_route_clippy.c:255
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #12 0x7f163e593f16 in event_call lib/event.c:1995
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #14 0x562bf414e58d in main bgpd/bgp_main.c:505
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-SUMMARY: AddressSanitizer: 304 byte(s) leaked in 2 allocation(s).

Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix memory leak when updating peer up loc rib events

92f9848

The following memory leak can be observed when turning off and on the
BGP vrf interface.

> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     #4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     #5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     #6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     #7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     #8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     #9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     #10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     #11 0x7fbf5f18078d in event_call lib/event.c:1996
>     #12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     #13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     #14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
>     #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     #4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     #5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     #6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     #7 0x7fbf5f18078d in event_call lib/event.c:1996
>     #8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     #9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     #10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: bmp, fix memory leak in peer messages

3e63abf

The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     #2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     #4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     #5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     #6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     #7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     #8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     #9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     #10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     #11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     #12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     #13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     #14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     #15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     #2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     #3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     #4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     #5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     #6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     #7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     #8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     #9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     #10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     #11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     #12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     #13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     #14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     #15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     #2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     #4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     #5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     #6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     #7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     #8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     #9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     #10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     #11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     #12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     #13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     #14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     #2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     #3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     #4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     #5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     #6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     #7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     #8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     #9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     #10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     #11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     #12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     #13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     #1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     #2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     #3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     #4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     #5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     #6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     #7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     #8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     #9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     #10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     #11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     #12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     #13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     #14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix access to invalid memory zone

3e05ba0

> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
>     #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
>     #1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     #2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     #3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     #4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     #5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     #6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     #7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     #8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     #9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     #10 0x7f738998078d in event_call lib/event.c:1996
>     #11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     #12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     #13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     #14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     #15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

9f7177a

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

ac31df3

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

f37e1ee

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

146a376

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

b0b589e

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

aba588d

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 pushed a commit that referenced this pull request


          bgpd: fix duplicate BGP instance created with unified config

3abd84e

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: fix table heap-after-free crash

7395e39

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>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: Fix neigh delete causing heap-use-after-free error

3060afc

Issue:
Not freeing the neighbor n  within the same function can lead to
memory leak.
zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free

Fix: not accessing n after its freed.
Directly free the neighbor entry (n) when its interface index matches
ifp->ifindex.

This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
    #0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
    #1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
    #2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
    #3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
    #4 0x55f95a0f819d in if_down zebra/interface.c:1017
    #5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
    #6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
    #7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
    #8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
    #9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
    #10 0x55f95a11ca7f in main zebra/main.c:543
    #11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)

Ticket: FRRouting#18047

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>

NetDEF-CI pushed a commit that referenced this pull request


          isisd: fix asla memory leak

fe2a07a

> ==713776==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 120 byte(s) in 1 object(s) allocated from:
>     #0 0x7fdfcbeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fdfcb86f8dd in qcalloc lib/memory.c:105
>     #2 0x55ce707739b6 in isis_tlvs_find_alloc_asla isisd/isis_tlvs.c:8500
>     #3 0x55ce7072fae0 in isis_link_params_update_asla isisd/isis_te.c:191
>     #4 0x55ce70733881 in isis_link_params_update isisd/isis_te.c:499
>     #5 0x55ce70693f2a in isis_circuit_up isisd/isis_circuit.c:776
>     #6 0x55ce7069a120 in isis_csm_state_change isisd/isis_csm.c:135
>     #7 0x55ce7068dd80 in isis_circuit_enable isisd/isis_circuit.c:79
>     #8 0x55ce70699346 in isis_ifp_create isisd/isis_circuit.c:1618
>     #9 0x7fdfcb81f47f in hook_call_if_real lib/if.c:55
>     #10 0x7fdfcb82056e in if_new_via_zapi lib/if.c:188
>     #11 0x7fdfcb9d17da in zclient_interface_add lib/zclient.c:2706
>     #12 0x7fdfcb9df842 in zclient_read lib/zclient.c:4843
>     #13 0x7fdfcb97798e in event_call lib/event.c:2011
>     #14 0x7fdfcb842ff1 in frr_run lib/libfrr.c:1216
>     #15 0x55ce7067cbf2 in main isisd/isis_main.c:360
>     #16 0x7fdfcb229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 8 byte(s) in 1 object(s) allocated from:
>     #0 0x7fdfcbeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fdfcb86f8dd in qcalloc lib/memory.c:105
>     #2 0x7fdfcb79a7b7 in admin_group_init lib/admin_group.c:186
>     #3 0x55ce707739ca in isis_tlvs_find_alloc_asla isisd/isis_tlvs.c:8501
>     #4 0x55ce7072fae0 in isis_link_params_update_asla isisd/isis_te.c:191
>     #5 0x55ce70733881 in isis_link_params_update isisd/isis_te.c:499
>     #6 0x55ce70693f2a in isis_circuit_up isisd/isis_circuit.c:776
>     #7 0x55ce7069a120 in isis_csm_state_change isisd/isis_csm.c:135
>     #8 0x55ce7068dd80 in isis_circuit_enable isisd/isis_circuit.c:79
>     #9 0x55ce70699346 in isis_ifp_create isisd/isis_circuit.c:1618
>     #10 0x7fdfcb81f47f in hook_call_if_real lib/if.c:55
>     #11 0x7fdfcb82056e in if_new_via_zapi lib/if.c:188
>     #12 0x7fdfcb9d17da in zclient_interface_add lib/zclient.c:2706
>     #13 0x7fdfcb9df842 in zclient_read lib/zclient.c:4843
>     #14 0x7fdfcb97798e in event_call lib/event.c:2011
>     #15 0x7fdfcb842ff1 in frr_run lib/libfrr.c:1216
>     #16 0x55ce7067cbf2 in main isisd/isis_main.c:360
>     #17 0x7fdfcb229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

PR: 95719
Fixes: 5749ac8 ("isisd: add ASLA support")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: fix pbr_iptable memory leak

92cdded

We are obviously doing deleting on wrong object.

> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>     #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105
>     #2 0x7fcf7124401a in list_new lib/linklist.c:49
>     #3 0x55771621d86d in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1015
>     #4 0x7fcf71217d79 in hash_get lib/hash.c:147
>     #5 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030
>     #6 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131
>     #7 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424
>     #8 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521
>     #9 0x7fcf7137798e in event_call lib/event.c:2011
>     #10 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216
>     #11 0x5577160e4d6d in main zebra/main.c:540
>     #12 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>     #0 0x7fcf718b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fcf7126f8dd in qcalloc lib/memory.c:105
>     #2 0x7fcf71244129 in listnode_new lib/linklist.c:71
>     #3 0x7fcf71244238 in listnode_add lib/linklist.c:92
>     #4 0x55771621d938 in pbr_iptable_alloc_intern zebra/zebra_pbr.c:1019
>     #5 0x7fcf71217d79 in hash_get lib/hash.c:147
>     #6 0x55771621dad3 in zebra_pbr_add_iptable zebra/zebra_pbr.c:1030
>     #7 0x55771614d00c in zread_iptable zebra/zapi_msg.c:4131
>     #8 0x55771614e586 in zserv_handle_commands zebra/zapi_msg.c:4424
>     #9 0x5577162dae2c in zserv_process_messages zebra/zserv.c:521
>     #10 0x7fcf7137798e in event_call lib/event.c:2011
>     #11 0x7fcf71242ff1 in frr_run lib/libfrr.c:1216
>     #12 0x5577160e4d6d in main zebra/main.c:540
>     #13 0x7fcf70c29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fixes: f80ec7e ("zebra: handle iptable list of interfaces")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix bgp_pbr_match_entry memory leak

520518c

> ==238132==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 160 byte(s) in 1 object(s) allocated from:
>     #0 0x7fd79f0b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fd79ea6f8dd in qcalloc lib/memory.c:105
>     #2 0x5586b26995f9 in bgp_pbr_match_entry_alloc_intern bgpd/bgp_pbr.c:1155
>     #3 0x7fd79ea17d79 in hash_get lib/hash.c:147
>     #4 0x5586b26a551d in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2522
>     #5 0x5586b26a6436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672
>     #6 0x5586b26a8089 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2876
>     #7 0x5586b26a8912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939
>     #8 0x5586b2829472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #9 0x5586b282ab4b in bgp_zebra_announce_table bgpd/bgp_zebra.c:1766
>     #10 0x5586b2824b99 in bgp_zebra_tm_connect bgpd/bgp_zebra.c:1091
>     #11 0x7fd79eb7798e in event_call lib/event.c:2011
>     #12 0x7fd79ea42ff1 in frr_run lib/libfrr.c:1216
>     #13 0x5586b2503a15 in main bgpd/bgp_main.c:545
>     #14 0x7fd79e429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix bgp_pbr_match memory leak

8d9df5c

> Direct leak of 1144 byte(s) in 13 object(s) allocated from:
>     #0 0x7f3eedeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f3eed86f8dd in qcalloc lib/memory.c:105
>     #2 0x55b32d236faf in bgp_pbr_match_alloc_intern bgpd/bgp_pbr.c:1074
>     #3 0x7f3eed817d79 in hash_get lib/hash.c:147
>     #4 0x55b32d242d9a in bgp_pbr_policyroute_add_to_zebra_unit bgpd/bgp_pbr.c:2486
>     #5 0x55b32d244436 in bgp_pbr_policyroute_add_to_zebra bgpd/bgp_pbr.c:2672
>     #6 0x55b32d245a05 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2843
>     #7 0x55b32d246912 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2939
>     #8 0x55b32d3c7472 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #9 0x55b32d26e5e7 in bgp_process_main_one bgpd/bgp_route.c:3691
>     #10 0x55b32d26f77d in process_subq_other_route bgpd/bgp_route.c:3856
>     #11 0x55b32d2701ff in process_subq bgpd/bgp_route.c:3955
>     #12 0x55b32d27029f in meta_queue_process bgpd/bgp_route.c:3980
>     #13 0x7f3eed99fdd8 in work_queue_run lib/workqueue.c:282
>     #14 0x7f3eed97798e in event_call lib/event.c:2011
>     #15 0x7f3eed842ff1 in frr_run lib/libfrr.c:1216
>     #16 0x55b32d0a1a15 in main bgpd/bgp_main.c:545
>     #17 0x7f3eed229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fixes: d114b0d ("bgpd: inject policy route entry from bgp into zebra pbr entries.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: fix bgp_pbr_or_filter memory leaks

eb8281a

Note that bgp_pbr_policyroute_add_from_zebra() and
bgp_pbr_policyroute_remove_from_zebra() are only called from
bgp_pbr_handle_entry().

>  ==966967==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>     #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fd44746f8dd in qcalloc lib/memory.c:105
>     #2 0x7fd44744401a in list_new lib/linklist.c:49
>     #3 0x560f8c094490 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2818
>     #4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941
>     #5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691
>     #7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856
>     #8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955
>     #9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980
>     #10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282
>     #11 0x7fd4475779b2 in event_call lib/event.c:2011
>     #12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216
>     #13 0x560f8bef0a15 in main bgpd/bgp_main.c:545
>     #14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>     #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fd44746f8dd in qcalloc lib/memory.c:105
>     #2 0x7fd44744401a in list_new lib/linklist.c:49
>     #3 0x560f8c09439d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2812
>     #4 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941
>     #5 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #6 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691
>     #7 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856
>     #8 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955
>     #9 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980
>     #10 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282
>     #11 0x7fd4475779b2 in event_call lib/event.c:2011
>     #12 0x7fd447442ff1 in frr_run lib/libfrr.c:1216
>     #13 0x560f8bef0a15 in main bgpd/bgp_main.c:545
>     #14 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 4 byte(s) in 1 object(s) allocated from:
>     #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fd44746f8dd in qcalloc lib/memory.c:105
>     #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362
>     #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400
>     #4 0x560f8c094530 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2819
>     #5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941
>     #6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691
>     #8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856
>     #9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955
>     #10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980
>     #11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282
>     #12 0x7fd4475779b2 in event_call lib/event.c:2011
>     #13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216
>     #14 0x560f8bef0a15 in main bgpd/bgp_main.c:545
>     #15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 4 byte(s) in 1 object(s) allocated from:
>     #0 0x7fd447ab4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fd44746f8dd in qcalloc lib/memory.c:105
>     #2 0x560f8c080cec in bgp_pbr_extract_enumerate_unary bgpd/bgp_pbr.c:362
>     #3 0x560f8c080f7e in bgp_pbr_extract_enumerate bgpd/bgp_pbr.c:400
>     #4 0x560f8c09443d in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2813
>     #5 0x560f8c095993 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2941
>     #6 0x560f8c2164f3 in bgp_zebra_announce bgpd/bgp_zebra.c:1618
>     #7 0x560f8c0bd668 in bgp_process_main_one bgpd/bgp_route.c:3691
>     #8 0x560f8c0be7fe in process_subq_other_route bgpd/bgp_route.c:3856
>     #9 0x560f8c0bf280 in process_subq bgpd/bgp_route.c:3955
>     #10 0x560f8c0bf320 in meta_queue_process bgpd/bgp_route.c:3980
>     #11 0x7fd44759fdfc in work_queue_run lib/workqueue.c:282
>     #12 0x7fd4475779b2 in event_call lib/event.c:2011
>     #13 0x7fd447442ff1 in frr_run lib/libfrr.c:1216
>     #14 0x560f8bef0a15 in main bgpd/bgp_main.c:545
>     #15 0x7fd446e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          zebra: fix heap-after-free on shutdown in netns mode

39f6549

Seen with bfd_vrf_topo1, and bgp_evpn_rt5 on Ubuntu 22.04 hwe.

Do not call ns_delete() from zebra_vrf_delete(), which calls
zebra_ns_delete().

- If a netns is removed from the system, vrf_delete()->zebra_vrf_delete()
  is called before calling ns_delete() (see zebra_ns_notify.c).
- If zebra is terminating, zebra_ns_final_shutdown() will call
  zebra_vrf_delete().

> ==616172==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000ae3a4 at pc 0x556cdc178d8f bp 0x7ffe4f41ace0 sp 0x7ffe4f41acd0
> READ of size 4 at 0x6160000ae3a4 thread T0
>     #0 0x556cdc178d8e in ctx_info_from_zns zebra/zebra_dplane.c:3394
>     #1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410
>     #2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759
>     #3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566
>     #4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793
>     #5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484
>     #6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804
>     #7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456
>     #8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633
>     #9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049
>     #10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903
>     #11 0x7fb25c173144 in route_node_free lib/table.c:75
>     #12 0x7fb25c17337f in route_table_free lib/table.c:111
>     #13 0x7fb25c172fe4 in route_table_finish lib/table.c:46
>     #14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191
>     #15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243
>     #16 0x556cdc10638b in zebra_finalize zebra/main.c:240
>     #17 0x7fb25c18e012 in event_call lib/event.c:2019
>     #18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247
>     #19 0x556cdc106deb in main zebra/main.c:543
>     #20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     #21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     #22 0x556cdc0c7ed4 in _start (/usr/lib/frr/zebra+0x192ed4)
>
> 0x6160000ae3a4 is located 36 bytes inside of 592-byte region [0x6160000ae380,0x6160000ae5d0)
> freed by thread T0 here:
>     #0 0x7fb25c6b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     #1 0x7fb25c0790e3 in qfree lib/memory.c:131
>     #2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261
>     #3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319
>     #4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343
>     #5 0x7fb25c197443 in vrf_delete lib/vrf.c:282
>     #6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601
>     #7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394
>     #8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609
>     #9 0x556cdc106345 in zebra_finalize zebra/main.c:223
>     #10 0x7fb25c18e012 in event_call lib/event.c:2019
>     #11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247
>     #12 0x556cdc106deb in main zebra/main.c:543
>     #13 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7fb25c6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fb25c078f91 in qcalloc lib/memory.c:106
>     #2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231
>     #3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429
>     #4 0x556cdc106cec in main zebra/main.c:480
>     #5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

30e479e

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

21e4934

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 30e479e)

NetDEF-CI pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

0df4fb5

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 30e479e)

ton31337 pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

939aa83

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 30e479e)

NetDEF-CI pushed a commit that referenced this pull request


          bgpd: free prefix in peer_group_listen_range_del

fa8ffbe

issue detected by Address Sanitizer Error :

Address Sanitizer Error detected in /tmp_topotests/bgp_listen_l3vrf.test_bgp_listen_l3vrf/r1.asan.bgpd.6703

=================================================================
==6703==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x7f34c28b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f34c241b45a in qcalloc lib/memory.c:111
    #2 0x7f34c247b1da in prefix_new lib/prefix.c:1192
    #3 0x55e0992e2041 in peer_group_listen_range_add bgpd/bgpd.c:3258
    #4 0x55e099282694 in bgp_listen_range bgpd/bgp_vty.c:4848
    #5 0x7f34c2397bc0 in cmd_execute_command_real lib/command.c:1011
    #6 0x7f34c2397edf in cmd_execute_command lib/command.c:1070
    #7 0x7f34c239840b in cmd_execute lib/command.c:1236
    #8 0x7f34c24e204e in vty_command lib/vty.c:626
    #9 0x7f34c24e259b in vty_execute lib/vty.c:1389
    #10 0x7f34c24e5f97 in vtysh_read lib/vty.c:2408
    #11 0x7f34c24d2958 in event_call lib/event.c:2005
    #12 0x7f34c23fc4e0 in frr_run lib/libfrr.c:1247
    #13 0x55e0990949ff in main bgpd/bgp_main.c:565
    #14 0x7f34c1e2c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 1 allocation(s).
***********************************************************************************

Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>

ton31337 pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

ff7447c

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 30e479e)

ton31337 pushed a commit that referenced this pull request


          nhrpd: fix crash when accessing invalid memory zone

bf46ccd

A crash is detected on an invalid memory access to the 0x0 address zone.

> #0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=130889386464320)
>     at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3  0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5  <signal handler called>
> #6  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
> #7  0x0000770b0f50bb54 in sockunion_set (su=0x7ffd4f7ed7b0, family=2, addr=0x0, bytes=4)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sockunion.c:500
> #8  0x00005f75d5430817 in nhrp_cie_pull (zb=0x5f75f262c4d0, hdr=0x5f75f2627dd8, nbma=0x7ffd4f7ed6d0,
>     proto=0x7ffd4f7ed7b0) at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:180
> #9  0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050
> #10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341
> #11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332
> #12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8)
>     at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317

The incoming nhrp packet is too short, and the call to sockunion_set()
uses a 0x0 memory zone, because the whole nhrp packet has been parsed,
and the zbuf length used was 0. Fix this by detecting the zbuf remaining
length before calling sockunion_set.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 30e479e)

ton31337 added a commit that referenced this pull request


          Revert "bgpd: Free up leaked bpme on release"

4c791a6

bgp_flowspec.test_bgp_flowspec_topo started to fail (crash) after this.

Let's revert it for now.

It's freed a bit above already:

	hash_release(bpm->entry_hash, bpme);
	bgp_pbr_match_entry_free(bpme);

    ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x60e00009f8a0
        #0 0x7f27d6cb7f04 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:119
        #1 0x7f27d6c264f6 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131
        #2 0x7f27d6c264f6 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1058
        #3 0x7f27d68254df in mt_count_free lib/memory.c:83
        #4 0x7f27d68254df in qfree lib/memory.c:135
        #5 0x5637d57b04a2 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977
        #6 0x5637d57b04a2 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1737
        #7 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980
        #8 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144
        #9 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781
        #10 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905
        #11 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733
        #12 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300
        #13 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318
        #14 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370
        #15 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212
        #16 0x5637d56961b4 in sigint bgpd/bgp_main.c:162
        #17 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117
        #18 0x7f27d68db77a in event_fetch lib/event.c:1742
        #19 0x7f27d68027e4 in frr_run lib/libfrr.c:1251
        #20 0x5637d5697c55 in main bgpd/bgp_main.c:569
        #21 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #22 0x7f27d630c304 in __libc_start_main_impl ../csu/libc-start.c:360
        #23 0x5637d5695ac0 in _start (/usr/lib/frr/bgpd+0x2cfac0)

    0x60e00009f8a0 is located 0 bytes inside of 160-byte region [0x60e00009f8a0,0x60e00009f940)
    freed by thread T0 here:
        #0 0x7f27d6cb76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
        #1 0x7f27d6825500 in qfree lib/memory.c:136
        #2 0x5637d57b0366 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977
        #3 0x5637d57b0366 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1715
        #4 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980
        #5 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144
        #6 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781
        #7 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905
        #8 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733
        #9 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300
        #10 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318
        #11 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370
        #12 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212
        #13 0x5637d56961b4 in sigint bgpd/bgp_main.c:162
        #14 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117
        #15 0x7f27d68db77a in event_fetch lib/event.c:1742
        #16 0x7f27d68027e4 in frr_run lib/libfrr.c:1251
        #17 0x5637d5697c55 in main bgpd/bgp_main.c:569
        #18 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

This reverts commit d0df550.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 added a commit that referenced this pull request


          bgpd: Free flowspec pointer that is allocated in prefix_copy()

a702e68

This fixes:

```
***********************************************************************************
Address Sanitizer Error detected in /tmp_topotests/bgp_flowspec.test_bgp_flowspec_topo/r1.asan.bgpd.31846

=================================================================
==31846==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 2 object(s) allocated from:
    #0 0x7f35488b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f3548424c0d in qcalloc lib/memory.c:111
    #2 0x7f354848278e in prefix_copy lib/prefix.c:349
    #3 0x7f35484cb9be in route_node_get lib/table.c:248
    #4 0x5562936aaf68 in bgp_node_get bgpd/bgp_table.h:246
    #5 0x5562936aaf68 in bgp_afi_node_get bgpd/bgp_route.c:204
    #6 0x5562936caa7c in bgp_update bgpd/bgp_route.c:5158
    #7 0x5562938a10f5 in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:186
    #8 0x55629367995c in bgp_nlri_parse bgpd/bgp_packet.c:324
    #9 0x55629367bd76 in bgp_update_receive bgpd/bgp_packet.c:2493
    #10 0x55629368ad39 in bgp_process_packet bgpd/bgp_packet.c:4066
    #11 0x7f35484dd6b7 in event_call lib/event.c:2009
    #12 0x7f35484027d9 in frr_run lib/libfrr.c:1252
    #13 0x556293577c55 in main bgpd/bgp_main.c:569
    #14 0x7f3547f0c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

ton31337 added a commit that referenced this pull request


          bgpd: Free flowspec pointer that is allocated in prefix_copy()

9dc67d9

This fixes:

```
***********************************************************************************
Address Sanitizer Error detected in /tmp_topotests/bgp_flowspec.test_bgp_flowspec_topo/r1.asan.bgpd.31846

=================================================================
==31846==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 2 object(s) allocated from:
    #0 0x7f35488b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f3548424c0d in qcalloc lib/memory.c:111
    #2 0x7f354848278e in prefix_copy lib/prefix.c:349
    #3 0x7f35484cb9be in route_node_get lib/table.c:248
    #4 0x5562936aaf68 in bgp_node_get bgpd/bgp_table.h:246
    #5 0x5562936aaf68 in bgp_afi_node_get bgpd/bgp_route.c:204
    #6 0x5562936caa7c in bgp_update bgpd/bgp_route.c:5158
    #7 0x5562938a10f5 in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:186
    #8 0x55629367995c in bgp_nlri_parse bgpd/bgp_packet.c:324
    #9 0x55629367bd76 in bgp_update_receive bgpd/bgp_packet.c:2493
    #10 0x55629368ad39 in bgp_process_packet bgpd/bgp_packet.c:4066
    #11 0x7f35484dd6b7 in event_call lib/event.c:2009
    #12 0x7f35484027d9 in frr_run lib/libfrr.c:1252
    #13 0x556293577c55 in main bgpd/bgp_main.c:569
    #14 0x7f3547f0c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

NetDEF-CI pushed a commit that referenced this pull request


          lib: Free Temporary Memory for AF_FLOWSPEC Prefix

881a5c1

This commit addresses a leak where temporary memory allocated
earlier by the `prefix_copy` function for AF_FLOWSPEC prefixes
was not being freed. To ensure proper memory management, we now
release this temporary memory by calling `prefix_flowspec_ptr_free`.

The ASan leak log for reference:

```
***********************************************************************************
Address Sanitizer Error detected in bgp_flowspec.test_bgp_flowspec_topo/r1.asan.bgpd.11539

=================================================================
==11539==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 2 object(s) allocated from:
    #0 0x7feaa956ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7feaa8f670da in qcalloc lib/memory.c:105
    #2 0x7feaa8fac1d4 in prefix_copy lib/prefix.c:346
    #3 0x7feaa8ff43e8 in route_node_get lib/table.c:274
    #4 0x56247cc798c0 in bgp_node_get bgpd/bgp_table.h:236
    #5 0x56247cc798c0 in bgp_afi_node_get bgpd/bgp_route.c:145
    #6 0x56247cc92622 in bgp_update bgpd/bgp_route.c:4188
    #7 0x56247ce55b21 in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:193
    #8 0x56247cc4cdd8 in bgp_nlri_parse bgpd/bgp_packet.c:350
    #9 0x56247cc4f37c in bgp_update_receive bgpd/bgp_packet.c:2153
    #10 0x56247cc591e2 in bgp_process_packet bgpd/bgp_packet.c:3214
    #11 0x7feaa9005b99 in event_call lib/event.c:1979
    #12 0x7feaa8f4a379 in frr_run lib/libfrr.c:1213
    #13 0x56247cb51b21 in main bgpd/bgp_main.c:510
    #14 0x7feaa7f8dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```

Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
(cherry picked from commit a7fe30e)

Conflicts:
	bgpd/bgp_table.c
	lib/prefix.c
	lib/prefix.h
	lib/table.c

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

NetDEF-CI pushed a commit that referenced this pull request


          ospfd: On cleanup, actually free vertexes

2d0f460

Upon examining this Indirect leak:

Indirect leak of 160 byte(s) in 4 object(s) allocated from:
    #0 0x7fe4f40b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7fe4f3c24c1d in qcalloc lib/memory.c:111
    #2 0x7fe4f3c03441 in list_new lib/linklist.c:49
    #3 0x564c81d076f9 in ospf_spf_vertex_copy ospfd/ospf_spf.c:335
    #4 0x564c81d0bff2 in ospf_spf_copy ospfd/ospf_spf.c:378
    #5 0x564c81d158e8 in ospf_ti_lfa_generate_p_space ospfd/ospf_ti_lfa.c:787
    #6 0x564c81d162f5 in ospf_ti_lfa_generate_p_spaces ospfd/ospf_ti_lfa.c:923
    #7 0x564c81d16532 in ospf_ti_lfa_compute ospfd/ospf_ti_lfa.c:1101
    #8 0x564c81d0e942 in ospf_spf_calculate_area ospfd/ospf_spf.c:1811
    #9 0x564c81d0eaa6 in ospf_spf_calculate_areas ospfd/ospf_spf.c:1840
    #10 0x564c81d0eda2 in ospf_spf_calculate_schedule_worker ospfd/ospf_spf.c:1871
    #11 0x7fe4f3cdd7c3 in event_call lib/event.c:2009
    #12 0x7fe4f3c027e9 in frr_run lib/libfrr.c:1252
    #13 0x564c81c95191 in main ospfd/ospf_main.c:307
    #14 0x7fe4f370c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

It was noticed that the vertex has another list that is not being
cleanedup.  Let's allow this to happen.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet