Skip to content

Conversation

@silasm
Copy link
Collaborator

@silasm silasm commented Apr 28, 2017

`systemctl' returns different, non-useful output while in a chroot.
Switch to checking if /sbin/init is a symlink to the systemd binary.
With this change the build works in a mock chroot.

Signed-off-by: Silas McCroskey [email protected]

`systemctl' returns different, non-useful output while in a chroot.
Switch to checking if /sbin/init is a symlink to the systemd binary.
With this change the build works in a mock chroot.

Signed-off-by: Silas McCroskey <[email protected]>
@mwinter-osr mwinter-osr merged commit bedc9ac into opensourcerouting:rpm-fixes-2.0 Apr 28, 2017
rwestphal added a commit that referenced this pull request Feb 21, 2019
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:

 (gdb) bt
 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 #1  0x00007ff7b267a42a in __GI_abort () at abort.c:89
 #2  0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
 #3  <signal handler called>
 #4  idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
 #5  0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
 #6  0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
 #7  bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
 #8  0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
 #9  0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
 #10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
 #11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
 #12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
 #13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
 #14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481

Add a null-check protection to fix this problem.

Signed-off-by: Renato Westphal <[email protected]>
rwestphal added a commit that referenced this pull request Feb 21, 2019
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:

 (gdb) bt
 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 #1  0x00007ff7b267a42a in __GI_abort () at abort.c:89
 #2  0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
 #3  <signal handler called>
 #4  idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
 #5  0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
 #6  0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
 #7  bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
 #8  0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
 #9  0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
 #10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
 #11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
 #12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
 #13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
 #14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481

Add a null-check protection to fix this problem.

Signed-off-by: Renato Westphal <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Oct 11, 2019
Our Address Sanitizer CI is finding this issue:
error	09-Oct-2019 19:28:33	r4: bgpd triggered an exception by AddressSanitizer
error	09-Oct-2019 19:28:33	ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540
error	09-Oct-2019 19:28:33	READ of size 1 at 0x7ffdd425b060 thread T0
error	09-Oct-2019 19:28:33	    #0 0x68575e in prefix_cmp lib/prefix.c:776
error	09-Oct-2019 19:28:33	    #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230
error	09-Oct-2019 19:28:33	    #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520
error	09-Oct-2019 19:28:33	    #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071
error	09-Oct-2019 19:28:33	    #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736
error	09-Oct-2019 19:28:33	    #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237
error	09-Oct-2019 19:28:33	    #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315
error	09-Oct-2019 19:28:33	    #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598
error	09-Oct-2019 19:28:33	    #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274
error	09-Oct-2019 19:28:33	    #9 0x6b9f54 in thread_call lib/thread.c:1531
error	09-Oct-2019 19:28:33	    #10 0x657037 in frr_run lib/libfrr.c:1052
error	09-Oct-2019 19:28:33	    #11 0x42d268 in main bgpd/bgp_main.c:486
error	09-Oct-2019 19:28:33	    #12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
error	09-Oct-2019 19:28:33	    #13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8)
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame
error	09-Oct-2019 19:28:33	    #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	  This frame has 5 object(s):
error	09-Oct-2019 19:28:33	    [32, 36) 'label'
error	09-Oct-2019 19:28:33	    [96, 108) 'rd_as'
error	09-Oct-2019 19:28:33	    [160, 172) 'rd_ip'
error	09-Oct-2019 19:28:33	    [224, 240) 'prd' <== Memory access at offset 240 overflows this variable
error	09-Oct-2019 19:28:33	    [288, 336) 'p'
error	09-Oct-2019 19:28:33	HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
error	09-Oct-2019 19:28:33	      (longjmp and C++ exceptions *are* supported)
error	09-Oct-2019 19:28:33	SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp
error	09-Oct-2019 19:28:33	Shadow bytes around the buggy address:
error	09-Oct-2019 19:28:33	  0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3
error	09-Oct-2019 19:28:33	  0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
error	09-Oct-2019 19:28:33	  0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2
error	09-Oct-2019 19:28:33	=>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2
error	09-Oct-2019 19:28:33	  0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00
error	09-Oct-2019 19:28:33	  0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4
error	09-Oct-2019 19:28:33	  0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	  0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	Shadow byte legend (one shadow byte represents 8 application bytes):
error	09-Oct-2019 19:28:33	  Addressable:           00
error	09-Oct-2019 19:28:33	  Partially addressable: 01 02 03 04 05 06 07
error	09-Oct-2019 19:28:33	  Heap left redzone:       fa
error	09-Oct-2019 19:28:33	  Heap right redzone:      fb
error	09-Oct-2019 19:28:33	  Freed heap region:       fd
error	09-Oct-2019 19:28:33	  Stack left redzone:      f1
error	09-Oct-2019 19:28:33	  Stack mid redzone:       f2
error	09-Oct-2019 19:28:33	  Stack right redzone:     f3
error	09-Oct-2019 19:28:33	  Stack partial redzone:   f4
error	09-Oct-2019 19:28:33	  Stack after return:      f5
error	09-Oct-2019 19:28:33	  Stack use after scope:   f8
error	09-Oct-2019 19:28:33	  Global redzone:          f9
error	09-Oct-2019 19:28:33	  Global init order:       f6
error	09-Oct-2019 19:28:33	  Poisoned by user:        f7
error	09-Oct-2019 19:28:33	  Container overflow:      fc
error	09-Oct-2019 19:28:33	  Array cookie:            ac
error	09-Oct-2019 19:28:33	  Intra object redzone:    bb
error	09-Oct-2019 19:28:33	  ASan internal:           fe
error	09-Oct-2019 19:28:36	r3: Daemon bgpd not running

This is the result of this code pattern in rfapi/rfapi_import.c:

prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd,
	   (struct prefix *)prd))

Effectively prd or vnc.import.rd are `struct prefix_rd` which
are being typecast to a `struct prefix`.  Not a big deal except commit
1315d74 modified the prefix_cmp
function to allow for a sorted prefix_cmp.  In prefix_cmp
we were looking at the offset and shift.  In the case
of vnc we were passing a prefix length of 64 which is the exact length of
the remaining data structure for struct prefix_rd.  So we calculated
a offset of 8 and a shift of 0.  The data structures for the prefix
portion happened to be equal to 64 bits of data. So we checked that
with the memcmp got a 0 and promptly read off the end of the data
structure for the numcmp.  The fix is if shift is 0 that means thei
the memcmp has checked everything and there is nothing to do.

Please note: We will still crash if we set the prefixlen > then
~312 bits currently( ie if the prefixlen specifies a bit length
longer than the prefix length ).  I do not think there is
anything to do here( nor am I sure how to correct this either )
as that we are going to have some severe problems when we muck
up the prefixlen.

Fixes: FRRouting#5025
Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Oct 15, 2019
Our Address Sanitizer CI is finding this issue:
error	09-Oct-2019 19:28:33	r4: bgpd triggered an exception by AddressSanitizer
error	09-Oct-2019 19:28:33	ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540
error	09-Oct-2019 19:28:33	READ of size 1 at 0x7ffdd425b060 thread T0
error	09-Oct-2019 19:28:33	    #0 0x68575e in prefix_cmp lib/prefix.c:776
error	09-Oct-2019 19:28:33	    #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230
error	09-Oct-2019 19:28:33	    #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520
error	09-Oct-2019 19:28:33	    #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071
error	09-Oct-2019 19:28:33	    #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736
error	09-Oct-2019 19:28:33	    #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237
error	09-Oct-2019 19:28:33	    #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315
error	09-Oct-2019 19:28:33	    #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598
error	09-Oct-2019 19:28:33	    #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274
error	09-Oct-2019 19:28:33	    #9 0x6b9f54 in thread_call lib/thread.c:1531
error	09-Oct-2019 19:28:33	    #10 0x657037 in frr_run lib/libfrr.c:1052
error	09-Oct-2019 19:28:33	    #11 0x42d268 in main bgpd/bgp_main.c:486
error	09-Oct-2019 19:28:33	    #12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
error	09-Oct-2019 19:28:33	    #13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8)
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame
error	09-Oct-2019 19:28:33	    #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	  This frame has 5 object(s):
error	09-Oct-2019 19:28:33	    [32, 36) 'label'
error	09-Oct-2019 19:28:33	    [96, 108) 'rd_as'
error	09-Oct-2019 19:28:33	    [160, 172) 'rd_ip'
error	09-Oct-2019 19:28:33	    [224, 240) 'prd' <== Memory access at offset 240 overflows this variable
error	09-Oct-2019 19:28:33	    [288, 336) 'p'
error	09-Oct-2019 19:28:33	HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
error	09-Oct-2019 19:28:33	      (longjmp and C++ exceptions *are* supported)
error	09-Oct-2019 19:28:33	SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp
error	09-Oct-2019 19:28:33	Shadow bytes around the buggy address:
error	09-Oct-2019 19:28:33	  0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3
error	09-Oct-2019 19:28:33	  0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
error	09-Oct-2019 19:28:33	  0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2
error	09-Oct-2019 19:28:33	=>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2
error	09-Oct-2019 19:28:33	  0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00
error	09-Oct-2019 19:28:33	  0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4
error	09-Oct-2019 19:28:33	  0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	  0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	Shadow byte legend (one shadow byte represents 8 application bytes):
error	09-Oct-2019 19:28:33	  Addressable:           00
error	09-Oct-2019 19:28:33	  Partially addressable: 01 02 03 04 05 06 07
error	09-Oct-2019 19:28:33	  Heap left redzone:       fa
error	09-Oct-2019 19:28:33	  Heap right redzone:      fb
error	09-Oct-2019 19:28:33	  Freed heap region:       fd
error	09-Oct-2019 19:28:33	  Stack left redzone:      f1
error	09-Oct-2019 19:28:33	  Stack mid redzone:       f2
error	09-Oct-2019 19:28:33	  Stack right redzone:     f3
error	09-Oct-2019 19:28:33	  Stack partial redzone:   f4
error	09-Oct-2019 19:28:33	  Stack after return:      f5
error	09-Oct-2019 19:28:33	  Stack use after scope:   f8
error	09-Oct-2019 19:28:33	  Global redzone:          f9
error	09-Oct-2019 19:28:33	  Global init order:       f6
error	09-Oct-2019 19:28:33	  Poisoned by user:        f7
error	09-Oct-2019 19:28:33	  Container overflow:      fc
error	09-Oct-2019 19:28:33	  Array cookie:            ac
error	09-Oct-2019 19:28:33	  Intra object redzone:    bb
error	09-Oct-2019 19:28:33	  ASan internal:           fe
error	09-Oct-2019 19:28:36	r3: Daemon bgpd not running

This is the result of this code pattern in rfapi/rfapi_import.c:

prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd,
	   (struct prefix *)prd))

Effectively prd or vnc.import.rd are `struct prefix_rd` which
are being typecast to a `struct prefix`.  Not a big deal except commit
1315d74 modified the prefix_cmp
function to allow for a sorted prefix_cmp.  In prefix_cmp
we were looking at the offset and shift.  In the case
of vnc we were passing a prefix length of 64 which is the exact length of
the remaining data structure for struct prefix_rd.  So we calculated
a offset of 8 and a shift of 0.  The data structures for the prefix
portion happened to be equal to 64 bits of data. So we checked that
with the memcmp got a 0 and promptly read off the end of the data
structure for the numcmp.  The fix is if shift is 0 that means thei
the memcmp has checked everything and there is nothing to do.

Please note: We will still crash if we set the prefixlen > then
~312 bits currently( ie if the prefixlen specifies a bit length
longer than the prefix length ).  I do not think there is
anything to do here( nor am I sure how to correct this either )
as that we are going to have some severe problems when we muck
up the prefixlen.

Fixes: FRRouting#5025
Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Nov 13, 2019
This code is called from the zebra main pthread during shutdown
but the thread event is scheduled via the zebra dplane pthread.

Hence, we should be using the `thread_cancel_async()` API to
cancel the thread event on a different pthread.

This is only ever hit in the rare case that we still have work left
to do on the update queue during shutdown.

Found via zebra crash:

```
(gdb) bt
\#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
\#1  0x00007f4e4d3f7535 in __GI_abort () at abort.c:79
\#2  0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()",
    file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92
\#3  0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c",
    line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101
\#4  0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185
\#5  0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274
\#6  0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202
\#7  0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599
\#8  0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024
\#9  0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483
(gdb) down
\#4  0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185
1185		assert(master->owner == pthread_self());
(gdb)
```

Signed-off-by: Stephen Worley <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Dec 18, 2019
Address Sanitizer is reporting this issue:

==26177==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120000238d8 at pc 0x7f88f7c4fa93 bp 0x7fff9a641830 sp 0x7fff9a641820
READ of size 8 at 0x6120000238d8 thread T0
    #0 0x7f88f7c4fa92 in if_delete lib/if.c:290
    #1 0x42192e in ospf_vl_if_delete ospfd/ospf_interface.c:912
    #2 0x42192e in ospf_vl_delete ospfd/ospf_interface.c:990
    #3 0x4a6208 in no_ospf_area_vlink ospfd/ospf_vty.c:1227
    #4 0x7f88f7c1553d in cmd_execute_command_real lib/command.c:1073
    #5 0x7f88f7c19b1e in cmd_execute_command lib/command.c:1132
    #6 0x7f88f7c19e8e in cmd_execute lib/command.c:1288
    #7 0x7f88f7cd7523 in vty_command lib/vty.c:516
    #8 0x7f88f7cd79ff in vty_execute lib/vty.c:1285
    #9 0x7f88f7cde4f9 in vtysh_read lib/vty.c:2119
    #10 0x7f88f7ccb845 in thread_call lib/thread.c:1549
    #11 0x7f88f7c5d6a7 in frr_run lib/libfrr.c:1093
    #12 0x412976 in main ospfd/ospf_main.c:221
    #13 0x7f88f73b082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x413c78 in _start (/usr/local/master/sbin/ospfd+0x413c78)

Effectively we are in a shutdown phase and as part of shutdown we delete the
ospf interface pointer ( ifp->info ).  The interface deletion code
was modified in the past year to pass in the address of operator
to allow us to NULL out the holding pointer.  The catch here
is that we free the oi and then delete the interface passing
in the address of the oi->ifp pointer, causing a use after free.

Fixes: FRRouting#5555
Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Dec 26, 2019
We were not connecting the default zebra_ns to the default
ns->info at namespace initialization in zebra. Thus, when
we tried to use the `ns_walk_func()` it would ignore the
default zebra_ns since there is no pointer to it from the
ns struct.

Fix this by connecting them in `zebra_ns_init()` and,
if the default ns is not found, exit with failure
since this is not recoverable.

This was found during a crash where we fail to cancel the kernel_read
thread at termination (via the `ns_walk_func()`) and then we
get a netlink notification trying to use the zns struct that has
already been freed.

```
(gdb) bt
\#0  0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
\#1  0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
\#2  0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254
\#3  <signal handler called>
\#4  0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269
\#5  0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043
\#6  0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384
\#7  0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940,
    count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932
\#8  0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406
\#9  0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599
\#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024
\#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483
```

Signed-off-by: Stephen Worley <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Jan 7, 2020
=================================================================
==13611==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe9e5c8694 at pc 0x0000004d18ac bp 0x7ffe9e5c8330 sp 0x7ffe9e5c7ae0
WRITE of size 17 at 0x7ffe9e5c8694 thread T0
    #0 0x4d18ab in __asan_memcpy (/usr/lib/frr/zebra+0x4d18ab)
    #1 0x7f16f04bd97f in stream_get2 /home/qlyoung/frr/lib/stream.c:277:2
    #2 0x6410ec in zebra_vxlan_remote_macip_del /home/qlyoung/frr/zebra/zebra_vxlan.c:7718:4
    #3 0x68fa98 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3
    #4 0x556add in main /home/qlyoung/frr/zebra/main.c:309:2
    #5 0x7f16eea3bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #6 0x431249 in _start (/usr/lib/frr/zebra+0x431249)

This decode is the result of a buffer overflow because we are
not checking ipa_len.

Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Jan 7, 2020
=================================================================
==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0)
==3058==The signal is caused by a READ memory access.
==3058==Hint: address points to the zero page.
    #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134
    #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a)
    #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3
    #3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2
    #4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c
    #5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4
    #6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3
    #7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2
    #8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9)

the ipset->backpointer was NULL as that the hash lookup failed to find
anything.  Prevent this crash from happening.

Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Jan 8, 2020
Running with --enable-address-sanitizer I am seeing this:

=================================================================
==19520==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ef850 at pc 0x7fe9b8f7b57b bp 0x7fffbac6f9c0 sp 0x7fffbac6f170
READ of size 6 at 0x6020003ef850 thread T0
    #0 0x7fe9b8f7b57a  (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
    #1 0x55e33d1071e5 in bgp_process_mac_rescan_table bgpd/bgp_mac.c:159
    #2 0x55e33d107c09 in bgp_mac_rescan_evpn_table bgpd/bgp_mac.c:252
    #3 0x55e33d107e39 in bgp_mac_rescan_all_evpn_tables bgpd/bgp_mac.c:266
    #4 0x55e33d108270 in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:291
    #5 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351
    #6 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257
    #7 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198
    #8 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549
    #9 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693
    #10 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
    #11 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
    #12 0x55e33d09d463 in main bgpd/bgp_main.c:477
    #13 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308
    #14 0x55e33d09c189 in _start (/usr/lib/frr/bgpd+0x168189)
0x6020003ef850 is located 0 bytes inside of 16-byte region [0x6020003ef850,0x6020003ef860)
freed by thread T0 here:
    #0 0x7fe9b8fabfb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
    #1 0x7fe9b8ce4ea9 in qfree lib/memory.c:129
    #2 0x55e33d10825c in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:289
    #3 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351
    #4 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257
    #5 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198
    #6 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549
    #7 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693
    #8 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
    #9 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
    #10 0x55e33d09d463 in main bgpd/bgp_main.c:477
    #11 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
    #0 0x7fe9b8fac518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
    #1 0x7fe9b8ce4d93 in qcalloc lib/memory.c:110
    #2 0x55e33d106b29 in bgp_mac_hash_alloc bgpd/bgp_mac.c:96
    #3 0x7fe9b8cb8350 in hash_get lib/hash.c:149
    #4 0x55e33d10845b in bgp_mac_add_mac_entry bgpd/bgp_mac.c:303
    #5 0x55e33d226757 in bgp_ifp_create bgpd/bgp_zebra.c:2644
    #6 0x7fe9b8cbf1e6 in if_new_via_zapi lib/if.c:176
    #7 0x7fe9b8db2d3b in zclient_interface_add lib/zclient.c:1481
    #8 0x7fe9b8db87f8 in zclient_read lib/zclient.c:2659
    #9 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
    #10 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
    #11 0x55e33d09d463 in main bgpd/bgp_main.c:477
    #12 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308

Effectively we are passing to bgp_mac_remove_ifp_internal the macaddr
that is associated with the bsm data structure.  There exists a path
where the bsm is freed and then we immediately pass the macaddr into
bgp_mac_rescan_all_evpn_tables.  So just make a copy of the macaddr
data structure before we free the bsm

Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Jan 16, 2020
The only two safi's that are usable for zebra for installation
of routes into the rib are SAFI_UNICAST and SAFI_MULTICAST.
The acceptance of other safi's is causing a memory leak:

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x5332f2 in calloc (/usr/lib/frr/zebra+0x5332f2)
    #1 0x7f594adc29db in qcalloc /opt/build/frr/lib/memory.c:110:27
    #2 0x686849 in zebra_vrf_get_table_with_table_id /opt/build/frr/zebra/zebra_vrf.c:390:11
    #3 0x65a245 in rib_add_multipath /opt/build/frr/zebra/zebra_rib.c:2591:10
    #4 0x7211bc in zread_route_add /opt/build/frr/zebra/zapi_msg.c:1616:8
    #5 0x73063c in zserv_handle_commands /opt/build/frr/zebra/zapi_msg.c:2682:2
Collapse

Sequence of events:

Upon vrf creation there is a zvrf->table[afi][safi] data structure
that tables are auto created for.  These tables only create SAFI_UNICAST
and SAFI_MULTICAST tables.  Since these are the only safi types that
are zebra can actually work on.  zvrf data structures also have a
zvrf->otable data structure that tracks in a RB tree other tables
that are created ( say you have routes stuck in any random table
in the 32bit route table space in linux ).  This data structure is
only used if the lookup in zvrf->table[afi][safi] fails.

After creation if we pass a route down from an upper level protocol
that has non unicast or multicast safi *but* has the actual
tableid of the vrf we are in, the initial lookup will always
return NULL leaving us to look in the otable.  This will create
a data structure to track this data.

If after this event you pass in a second route with the same
afi/safi/table_id, the otable will be created and attempted
to be stored, but the RB_TREE_UNIQ data structure when it sees
this will return the original otable returned and the lookup function
zebra_vrf_get_table_with_table_id will just drop the second otable.

Signed-off-by: Quentin Young <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Jan 16, 2020
==25402==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x533302 in calloc (/usr/lib/frr/zebra+0x533302)
    #1 0x7fee84cdc80b in qcalloc /home/qlyoung/frr/lib/memory.c:110:27
    #2 0x5a3032 in create_label_chunk /home/qlyoung/frr/zebra/label_manager.c:188:3
    #3 0x5a3c2b in assign_label_chunk /home/qlyoung/frr/zebra/label_manager.c:354:8
    #4 0x5a2a38 in label_manager_get_chunk /home/qlyoung/frr/zebra/label_manager.c:424:9
    #5 0x5a1412 in hook_call_lm_get_chunk /home/qlyoung/frr/zebra/label_manager.c:60:1
    #6 0x5a1412 in lm_get_chunk_call /home/qlyoung/frr/zebra/label_manager.c:81:2
    #7 0x72a234 in zread_get_label_chunk /home/qlyoung/frr/zebra/zapi_msg.c:2026:2
    #8 0x72a234 in zread_label_manager_request /home/qlyoung/frr/zebra/zapi_msg.c:2073:4
    #9 0x73150c in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2688:2

When creating label chunk that has a specified base, we eventually are
calling assign_specific_label_chunk. This function finds the appropriate
list node and deletes it from the lbl_mgr.lc_list but since
the function uses list_delete_node() the deletion function that is
specified for lbl_mgr.lc_list is not called thus dropping the memory.

Signed-off-by: Quentin Young <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Mar 10, 2020
Upper level clients ask for default routes of a particular family
This change ensures that they only receive the family that they
have asked for.

Discovered when testing in ospf `default-information originate`

=================================================================
==246306==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffa2e8 at pc 0x7ffff73c44e2 bp 0x7fffffffa090 sp 0x7fffffffa088
READ of size 16 at 0x7fffffffa2e8 thread T0
    #0 0x7ffff73c44e1 in prefix_copy lib/prefix.c:310
    #1 0x7ffff741c0aa in route_node_lookup lib/table.c:255
    #2 0x5555556cd263 in ospf_external_info_delete ospfd/ospf_asbr.c:178
    #3 0x5555556a47cc in ospf_zebra_read_route ospfd/ospf_zebra.c:852
    #4 0x7ffff746f5d8 in zclient_read lib/zclient.c:3028
    #5 0x7ffff742fc91 in thread_call lib/thread.c:1549
    #6 0x7ffff7374642 in frr_run lib/libfrr.c:1093
    #7 0x5555555bfaef in main ospfd/ospf_main.c:235
    #8 0x7ffff70a2bba in __libc_start_main ../csu/libc-start.c:308
    #9 0x5555555bf499 in _start (/usr/lib/frr/ospfd+0x6b499)

Signed-off-by: Donald Sharp <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Apr 5, 2020
Implement tests to verify BGP link-bandwidth and weighted ECMP
functionality. These tests validate one of the primary use cases for
weighted ECMP (a.k.a. Unequal cost multipath) using BGP link-bandwidth:
https://tools.ietf.org/html/draft-mohanty-bess-ebgp-dmz

The included tests are:
Test #1: Test BGP link-bandwidth advertisement based on number of multipaths
Test #2: Test cumulative link-bandwidth propagation
Test #3: Test weighted ECMP - multipath with next hop weights
Test #4: Test weighted ECMP rebalancing upon change (link flap)
Test #5: Test weighted ECMP for a second anycast IP
Test #6: Test paths with and without link-bandwidth - receiver should resort to regular ECMP
Test #7: Test different options for processing link-bandwidth on the receiver

Signed-off-by: Vivek Venkatraman <[email protected]>
mwinter-osr pushed a commit that referenced this pull request Sep 24, 2020
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 6, 2020
Current code in bgp bestpath selection would accept the newest
locally originated path as the best path.  Making the selection
non-deterministic.  Modify the code to always come to the
same bestpath conclusion when you have multiple locally originated
paths in bestpath selection.

Before:

eva# conf
eva(config)# router bgp 323
eva(config-router)# address-family ipv4 uni
eva(config-router-af)# redistribute connected
eva(config-router-af)# network 192.168.161.0/24
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:02:52 2020
eva(config-router-af)# no redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#  redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:03:32 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#

Notice the route choosen depends on order received

Fixed behavior:

eva# conf
eva(config)# router bgp 323
eva(config-router)# address-family ipv4 uni
eva(config-router-af)# redistribute connected
eva(config-router-af)# network 192.168.161.0/24
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:02:52 2020
eva(config-router-af)# no redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#  redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:03:32 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#

Ticket: CM-31490
Found-by: Trey Aspelund <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 8, 2020
The bgp_l3vpn_to_bgp_vrf test is looking for a prefix
on multiple routers that the ordered received is non-deterministic.
As such the regex's are failing occassionaly when the
route is received in an unexpected order.

One possible order:
(#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c:
COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M
Paths: (2 available, best #1, table default)^M
  Advertised to non peer-group peers:^M
  192.168.1.1^M
  Local^M
    99.0.0.3 from 0.0.0.0 (99.0.0.3)^M
      Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M
      Community: 0:67^M
      Extended Community: RT:89:123^M
      Large Community: 12:34:56^M
      Last update: Wed Oct  7 11:12:22 2020^M
  Local^M
    192.168.1.1 from 192.168.1.1 (192.168.1.1)^M
      Origin IGP, metric 98, localpref 123, valid, internal^M
      Community: 0:67^M
      Extended Community: RT:52:100 RT:89:123^M
      Large Community: 12:34:56^M
      Last update: Wed Oct  7 11:12:41 2020:
R:89   ce3    Redundant route 1 details c                              1    0

Second possible order:
(#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c:
COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M
Paths: (2 available, best #2, table default)^M
  Advertised to non peer-group peers:^M
  192.168.1.1^M
  Local^M
    192.168.1.1 from 192.168.1.1 (192.168.1.1)^M
      Origin IGP, metric 98, localpref 123, valid, internal^M
      Community: 0:67^M
      Extended Community: RT:52:100 RT:89:123^M
      Large Community: 12:34:56^M
      Last update: Wed Oct  7 11:14:45 2020^M
  Local^M
    99.0.0.3 from 0.0.0.0 (99.0.0.3)^M
      Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M
      Community: 0:67^M
      Extended Community: RT:89:123^M
      Large Community: 12:34:56^M
      Last update: Wed Oct  7 11:14:27 2020:
R:89   ce3    Redundant route 1 details c                              0    1

BGP displays the paths in the order received since it's just a linked list.
For this test modify/add the luCommands to track that we may
receive the paths in a non-deterministic order.

Signed-off-by: Donald Sharp <[email protected]>
Signed-off-by: Quentin Young <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 9, 2020
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 17, 2020
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 18, 2020
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 23, 2020
Fixes the valgrind error we were seeing on startup due to
initializing the msg header struct:

```
==2534283== Thread 3 zebra_dplane:
==2534283== Syscall param recvmsg(msg) points to uninitialised byte(s)
==2534283==    at 0x4D616DD: recvmsg (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x43107C: netlink_recv_msg (kernel_netlink.c:744)
==2534283==    by 0x4330E4: nl_batch_read_resp (kernel_netlink.c:1070)
==2534283==    by 0x431D12: nl_batch_send (kernel_netlink.c:1201)
==2534283==    by 0x431E8B: kernel_update_multi (kernel_netlink.c:1369)
==2534283==    by 0x46019B: kernel_dplane_process_func (zebra_dplane.c:3979)
==2534283==    by 0x45EB7F: dplane_thread_loop (zebra_dplane.c:4368)
==2534283==    by 0x493F5CC: thread_call (thread.c:1585)
==2534283==    by 0x48D3450: fpt_run (frr_pthread.c:303)
==2534283==    by 0x48D3D41: frr_pthread_inner (frr_pthread.c:156)
==2534283==    by 0x4D56431: start_thread (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x4E709D2: clone (in /usr/lib64/libc-2.31.so)
==2534283==  Address 0x85cd850 is on thread 3's stack
==2534283==  in frame #2, created by nl_batch_read_resp (kernel_netlink.c:1051)
==2534283==
==2534283== Syscall param recvmsg(msg.msg_control) points to unaddressable byte(s)
==2534283==    at 0x4D616DD: recvmsg (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x43107C: netlink_recv_msg (kernel_netlink.c:744)
==2534283==    by 0x4330E4: nl_batch_read_resp (kernel_netlink.c:1070)
==2534283==    by 0x431D12: nl_batch_send (kernel_netlink.c:1201)
==2534283==    by 0x431E8B: kernel_update_multi (kernel_netlink.c:1369)
==2534283==    by 0x46019B: kernel_dplane_process_func (zebra_dplane.c:3979)
==2534283==    by 0x45EB7F: dplane_thread_loop (zebra_dplane.c:4368)
==2534283==    by 0x493F5CC: thread_call (thread.c:1585)
==2534283==    by 0x48D3450: fpt_run (frr_pthread.c:303)
==2534283==    by 0x48D3D41: frr_pthread_inner (frr_pthread.c:156)
==2534283==    by 0x4D56431: start_thread (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x4E709D2: clone (in /usr/lib64/libc-2.31.so)
==2534283==  Address 0xa0 is not stack'd, malloc'd or (recently) free'd
==2534283==
```

Signed-off-by: Stephen Worley <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 28, 2020
Fixes the valgrind error we were seeing on startup due to
initializing the msg header struct:

```
==2534283== Thread 3 zebra_dplane:
==2534283== Syscall param recvmsg(msg) points to uninitialised byte(s)
==2534283==    at 0x4D616DD: recvmsg (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x43107C: netlink_recv_msg (kernel_netlink.c:744)
==2534283==    by 0x4330E4: nl_batch_read_resp (kernel_netlink.c:1070)
==2534283==    by 0x431D12: nl_batch_send (kernel_netlink.c:1201)
==2534283==    by 0x431E8B: kernel_update_multi (kernel_netlink.c:1369)
==2534283==    by 0x46019B: kernel_dplane_process_func (zebra_dplane.c:3979)
==2534283==    by 0x45EB7F: dplane_thread_loop (zebra_dplane.c:4368)
==2534283==    by 0x493F5CC: thread_call (thread.c:1585)
==2534283==    by 0x48D3450: fpt_run (frr_pthread.c:303)
==2534283==    by 0x48D3D41: frr_pthread_inner (frr_pthread.c:156)
==2534283==    by 0x4D56431: start_thread (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x4E709D2: clone (in /usr/lib64/libc-2.31.so)
==2534283==  Address 0x85cd850 is on thread 3's stack
==2534283==  in frame #2, created by nl_batch_read_resp (kernel_netlink.c:1051)
==2534283==
==2534283== Syscall param recvmsg(msg.msg_control) points to unaddressable byte(s)
==2534283==    at 0x4D616DD: recvmsg (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x43107C: netlink_recv_msg (kernel_netlink.c:744)
==2534283==    by 0x4330E4: nl_batch_read_resp (kernel_netlink.c:1070)
==2534283==    by 0x431D12: nl_batch_send (kernel_netlink.c:1201)
==2534283==    by 0x431E8B: kernel_update_multi (kernel_netlink.c:1369)
==2534283==    by 0x46019B: kernel_dplane_process_func (zebra_dplane.c:3979)
==2534283==    by 0x45EB7F: dplane_thread_loop (zebra_dplane.c:4368)
==2534283==    by 0x493F5CC: thread_call (thread.c:1585)
==2534283==    by 0x48D3450: fpt_run (frr_pthread.c:303)
==2534283==    by 0x48D3D41: frr_pthread_inner (frr_pthread.c:156)
==2534283==    by 0x4D56431: start_thread (in /usr/lib64/libpthread-2.31.so)
==2534283==    by 0x4E709D2: clone (in /usr/lib64/libc-2.31.so)
==2534283==  Address 0xa0 is not stack'd, malloc'd or (recently) free'd
==2534283==
```

Signed-off-by: Stephen Worley <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 30, 2020
The fields in the broadcast/p2p union struct in an isis circuit are
initialized when the circuit goes up, but currently this step is
skipped if the interface is passive. This can create problems if the
circuit type (referred to as network type in the config) changes from
broadcast to point-to-point. We can end up with the p2p neighbor
pointer pointing at some garbage left by the broadcast struct in the
union, which would then cause a segfault the first time we would
dereference it - for example when building the lsp, or computing the
SPF tree.

compressed backtrace of a possible crash:
 #0  0x0000555555579a9c in lsp_build at frr/isisd/isis_lsp.c:1114
 #1  0x000055555557a516 in lsp_regenerate at frr/isisd/isis_lsp.c:1301
 #2  0x000055555557aa25 in lsp_refresh at frr/isisd/isis_lsp.c:1381
 #3  0x00007ffff7b2622c in thread_call at frr/lib/thread.c:1549
 #4  0x00007ffff7ad6df4 in frr_run at frr/lib/libfrr.c:1098
 #5  0x000055555556b67f in main at frr/isisd/isis_main.c:272

isis_lsp.c:
1112	case CIRCUIT_T_P2P: {
1113		struct isis_adjacency *nei = circuit->u.p2p.neighbor;
1114		if (nei && nei->adj_state == ISIS_ADJ_UP

Signed-off-by: Emanuele Di Pascale <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Nov 3, 2020
Current code in bgp bestpath selection would accept the newest
locally originated path as the best path.  Making the selection
non-deterministic.  Modify the code to always come to the
same bestpath conclusion when you have multiple locally originated
paths in bestpath selection.

Before:

eva# conf
eva(config)# router bgp 323
eva(config-router)# address-family ipv4 uni
eva(config-router-af)# redistribute connected
eva(config-router-af)# network 192.168.161.0/24
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:02:52 2020
eva(config-router-af)# no redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#  redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:03:32 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#

Notice the route choosen depends on order received

Fixed behavior:

eva# conf
eva(config)# router bgp 323
eva(config-router)# address-family ipv4 uni
eva(config-router-af)# redistribute connected
eva(config-router-af)# network 192.168.161.0/24
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:02:52 2020
eva(config-router-af)# no redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#  redistribute connected
eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0
BGP routing table entry for 192.168.161.0/24
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin incomplete, metric 0, weight 32768, valid, sourced
      Last update: Wed Sep 16 15:03:32 2020
  Local
    0.0.0.0(eva) from 0.0.0.0 (192.168.161.245)
      Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin)
      Last update: Wed Sep 16 15:03:03 2020
eva(config-router-af)#

Ticket: CM-31490
Found-by: Trey Aspelund <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Nov 18, 2020
The fields in the broadcast/p2p union struct in an isis circuit are
initialized when the circuit goes up, but currently this step is
skipped if the interface is passive. This can create problems if the
circuit type (referred to as network type in the config) changes from
broadcast to point-to-point. We can end up with the p2p neighbor
pointer pointing at some garbage left by the broadcast struct in the
union, which would then cause a segfault the first time we would
dereference it - for example when building the lsp, or computing the
SPF tree.

compressed backtrace of a possible crash:
 #0  0x0000555555579a9c in lsp_build at frr/isisd/isis_lsp.c:1114
 #1  0x000055555557a516 in lsp_regenerate at frr/isisd/isis_lsp.c:1301
 #2  0x000055555557aa25 in lsp_refresh at frr/isisd/isis_lsp.c:1381
 #3  0x00007ffff7b2622c in thread_call at frr/lib/thread.c:1549
 #4  0x00007ffff7ad6df4 in frr_run at frr/lib/libfrr.c:1098
 #5  0x000055555556b67f in main at frr/isisd/isis_main.c:272

isis_lsp.c:
1112	case CIRCUIT_T_P2P: {
1113		struct isis_adjacency *nei = circuit->u.p2p.neighbor;
1114		if (nei && nei->adj_state == ISIS_ADJ_UP

Signed-off-by: Emanuele Di Pascale <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Nov 25, 2020
We are using data after it has been freed and handed back to the
OS.
Address Sanitizer output:

error	23-Nov-2020 18:53:57	ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55f825998f58 bp 0x7fffa5b0f5b0 sp 0x7fffa5b0f5a0
error	23-Nov-2020 18:53:57	READ of size 4 at 0x631000024838 thread T0
error	23-Nov-2020 18:53:57	    #0 0x55f825998f57 in lde_imsg_compose_parent_sync ldpd/lde.c:226
error	23-Nov-2020 18:53:57	    #1 0x55f8259ca9ed in vlog ldpd/log.c:48
error	23-Nov-2020 18:53:57	    #2 0x55f8259cb1c8 in log_info ldpd/log.c:102
error	23-Nov-2020 18:53:57	    #3 0x55f82599e841 in lde_shutdown ldpd/lde.c:208
error	23-Nov-2020 18:53:57	    #4 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #5 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #6 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #7 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #8 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57	    #9 0x55f825982579 in _start (/usr/lib/frr/ldpd+0xb3579)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error	23-Nov-2020 18:53:57	freed by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4d7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error	23-Nov-2020 18:53:57	    #1 0x55f82599e830 in lde_shutdown ldpd/lde.c:206
error	23-Nov-2020 18:53:57	    #2 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #3 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #4 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #5 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #6 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	previously allocated by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4dd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error	23-Nov-2020 18:53:57	    #1 0x55f825998cb7 in lde ldpd/lde.c:151
error	23-Nov-2020 18:53:57	    #2 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #3 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57

The fix is to put this in global space.

Signed-off-by: Donald Sharp <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Nov 27, 2020
error	26-Nov-2020 14:35:02	ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55cefae977e9 bp 0x7ffdd3546860 sp 0x7ffdd3546850
error	26-Nov-2020 14:35:02	READ of size 4 at 0x631000024838 thread T0
error	26-Nov-2020 14:35:02	    #0 0x55cefae977e8 in ldpe_imsg_compose_parent_sync ldpd/ldpe.c:256
error	26-Nov-2020 14:35:02	    #1 0x55cefae9ab13 in vlog ldpd/log.c:53
error	26-Nov-2020 14:35:02	    #2 0x55cefae9b21f in log_info ldpd/log.c:102
error	26-Nov-2020 14:35:02	    #3 0x55cefae96eae in ldpe_shutdown ldpd/ldpe.c:237
error	26-Nov-2020 14:35:02	    #4 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585
error	26-Nov-2020 14:35:02	    #5 0x55cefaf93875 in thread_call lib/thread.c:1681
error	26-Nov-2020 14:35:02	    #6 0x55cefae97304 in ldpe ldpd/ldpe.c:136
error	26-Nov-2020 14:35:02	    #7 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #8 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	26-Nov-2020 14:35:02	    #9 0x55cefae525e9 in _start (/usr/lib/frr/ldpd+0xb35e9)
error	26-Nov-2020 14:35:02
error	26-Nov-2020 14:35:02	0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error	26-Nov-2020 14:35:02	freed by thread T0 here:
error	26-Nov-2020 14:35:02	    #0 0x7f4ef21e37a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error	26-Nov-2020 14:35:02	    #1 0x55cefae96e91 in ldpe_shutdown ldpd/ldpe.c:234
error	26-Nov-2020 14:35:02	    #2 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585
error	26-Nov-2020 14:35:02	    #3 0x55cefaf93875 in thread_call lib/thread.c:1681
error	26-Nov-2020 14:35:02	    #4 0x55cefae97304 in ldpe ldpd/ldpe.c:136
error	26-Nov-2020 14:35:02	    #5 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #6 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	26-Nov-2020 14:35:02
error	26-Nov-2020 14:35:02	previously allocated by thread T0 here:
error	26-Nov-2020 14:35:02	    #0 0x7f4ef21e3d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error	26-Nov-2020 14:35:02	    #1 0x55cefae9725d in ldpe ldpd/ldpe.c:127
error	26-Nov-2020 14:35:02	    #2 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #3 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Clean this problem up in the same way as the previous commit

Signed-off-by: Donald Sharp <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Nov 30, 2020
We are using data after it has been freed and handed back to the
OS.
Address Sanitizer output:

error	23-Nov-2020 18:53:57	ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55f825998f58 bp 0x7fffa5b0f5b0 sp 0x7fffa5b0f5a0
error	23-Nov-2020 18:53:57	READ of size 4 at 0x631000024838 thread T0
error	23-Nov-2020 18:53:57	    #0 0x55f825998f57 in lde_imsg_compose_parent_sync ldpd/lde.c:226
error	23-Nov-2020 18:53:57	    #1 0x55f8259ca9ed in vlog ldpd/log.c:48
error	23-Nov-2020 18:53:57	    #2 0x55f8259cb1c8 in log_info ldpd/log.c:102
error	23-Nov-2020 18:53:57	    #3 0x55f82599e841 in lde_shutdown ldpd/lde.c:208
error	23-Nov-2020 18:53:57	    #4 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #5 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #6 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #7 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #8 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57	    #9 0x55f825982579 in _start (/usr/lib/frr/ldpd+0xb3579)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error	23-Nov-2020 18:53:57	freed by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4d7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error	23-Nov-2020 18:53:57	    #1 0x55f82599e830 in lde_shutdown ldpd/lde.c:206
error	23-Nov-2020 18:53:57	    #2 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #3 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #4 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #5 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #6 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	previously allocated by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4dd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error	23-Nov-2020 18:53:57	    #1 0x55f825998cb7 in lde ldpd/lde.c:151
error	23-Nov-2020 18:53:57	    #2 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #3 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57

The fix is to put this in global space.

Signed-off-by: Donald Sharp <[email protected]>
ton31337 pushed a commit that referenced this pull request May 20, 2025
Seen with isis_srv6_topo1 topotest.

> ==178793==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 56 byte(s) in 1 object(s) allocated from:
>     #0 0x7f3f63cb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f3f6366f8dd in qcalloc lib/memory.c:105
>     #2 0x561b810c62b7 in isis_srv6_sid_alloc isisd/isis_srv6.c:243
>     #3 0x561b8111f944 in isis_zebra_srv6_sid_notify isisd/isis_zebra.c:1534
>     #4 0x7f3f637df9d7 in zclient_read lib/zclient.c:4845
>     #5 0x7f3f637779b2 in event_call lib/event.c:2011
>     #6 0x7f3f63642ff1 in frr_run lib/libfrr.c:1216
>     #7 0x561b81018bf2 in main isisd/isis_main.c:360
>     #8 0x7f3f63029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Fixes: 0af0f46 ("isisd: Receive SRv6 SIDs notifications from zebra")
Signed-off-by: Louis Scalbert <[email protected]>
(cherry picked from commit 25c813a)
NetDEF-CI pushed a commit that referenced this pull request Jun 5, 2025
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 <[email protected]>
Signed-off-by: Philippe Guibert <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jun 16, 2025
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jun 16, 2025
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 <[email protected]>
(cherry picked from commit 30e479e)
NetDEF-CI pushed a commit that referenced this pull request Jun 16, 2025
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 <[email protected]>
(cherry picked from commit 30e479e)
ton31337 pushed a commit that referenced this pull request Jun 19, 2025
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 <[email protected]>
(cherry picked from commit 30e479e)
NetDEF-CI pushed a commit that referenced this pull request Jul 2, 2025
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jul 9, 2025
Memory leak happens when modifying srv6 configuration. Some sid
notifications events will flush a valid srv6 context.

> Direct leak of 736 byte(s) in 2 object(s) allocated from:
>     #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7c112bc3595e in qcalloc lib/memory.c:111
>     #2 0x7c112bc4d37e in srv6_locator_alloc lib/srv6.c:227
>     #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662
>     #4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804
>     #5 0x7c112bcfaa90 in event_call lib/event.c:2005
>     #6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252
>     #7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565
>     #8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     #9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360
>     #10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc)
>
> Indirect leak of 80 byte(s) in 2 object(s) allocated from:
>     #0 0x7c112c0fd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7c112bc3595e in qcalloc lib/memory.c:111
>     #2 0x7c112bc4d396 in srv6_locator_alloc lib/srv6.c:229
>     #3 0x5f9fa87e7acf in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3662
>     #4 0x7c112bd32d12 in zclient_read lib/zclient.c:4804
>     #5 0x7c112bcfaa90 in event_call lib/event.c:2005
>     #6 0x7c112bc118a7 in frr_run lib/libfrr.c:1252
>     #7 0x5f9fa85674b4 in main bgpd/bgp_main.c:565
>     #8 0x7c112b42a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     #9 0x7c112b42a28a in __libc_start_main_impl ../csu/libc-start.c:360
>     #10 0x5f9fa856cbd4 in _start (/usr/lib/frr/bgpd+0x2d5bd4) (BuildId: 16288c5292cf235ab5251a93b7dbae5874c3f4bc)

Fixes: 7a2e64e ("bgpd: Receive SRv6 SIDs notification from zebra")
Signed-off-by: Philippe Guibert <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jul 9, 2025
When SRv6 locator is modified for configuration, a memory leak is
observed.

> ==26714==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 1104 byte(s) in 3 object(s) allocated from:
>     #0 0x7fb232cb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
>     #1 0x7fb232822b79 in qcalloc lib/memory.c:111
>     #2 0x7fb23283a8b6 in srv6_locator_alloc lib/srv6.c:227
>     #3 0x56347cdd4b57 in bgp_zebra_srv6_sid_notify bgpd/bgp_zebra.c:3661
>     #4 0x7fb23290d03e in zclient_read lib/zclient.c:4804
>     #5 0x7fb2328da6a0 in event_call lib/event.c:2005
>     #6 0x7fb232800791 in frr_run lib/libfrr.c:1252
>     #7 0x56347cb929ff in main bgpd/bgp_main.c:565
>     #8 0x7fb23222c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jul 17, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jul 18, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit fa67f51)
NetDEF-CI pushed a commit that referenced this pull request Jul 18, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit fa67f51)
ton31337 pushed a commit that referenced this pull request Jul 28, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit fa67f51)
ton31337 pushed a commit that referenced this pull request Jul 28, 2025
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 <[email protected]>
(cherry picked from commit 30e479e)
ton31337 pushed a commit that referenced this pull request Jul 28, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit fa67f51)
ton31337 pushed a commit that referenced this pull request Jul 28, 2025
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 <[email protected]>
(cherry picked from commit 30e479e)
ton31337 pushed a commit that referenced this pull request Jul 28, 2025
The `match->rule_str` may is NULL, like:
```
ip prefix-list plist1 deny any
route-map rm1 deny 10
 match evpn default-route
```

The stack:
```
 #0  __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse4_2.S:173
 #1  0x00007ffff7e5a7ea in route_map_pentry_process_dependency (
     bucket=0x5555561fb270, data=0x7fffffff96e0) at ../lib/routemap.c:2466
 #2  0x00007ffff7de983d in hash_iterate (hash=0x555556208e50,
     func=0x7ffff7e5a6f3 <route_map_pentry_process_dependency>, arg=0x7fffffff96e0)
     at ../lib/hash.c:252
 #3  0x00007ffff7e5a99d in route_map_notify_pentry_dependencies (
     affected_name=0x5555561fb720 "plist1", pentry=0x555556201040,
     event=RMAP_EVENT_PLIST_ADDED) at ../lib/routemap.c:2513
 #4  0x00007ffff7e4a275 in prefix_list_entry_update_finish (ple=0x555556201040)
     at ../lib/plist.c:697
 #5  0x00007ffff7de38c9 in lib_prefix_list_entry_apply_finish (args=0x7fffffff97b0)
     at ../lib/filter_nb.c:1233
 #6  0x00007ffff7e3228a in nb_callback_apply_finish (context=0x555556204970,
     nb_node=0x555555b51860, dnode=0x5555561e47b0, errmsg=0x7fffffff9d00 "",
    errmsg_len=8192) at ../lib/northbound.c:1772
```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit fa67f51)
NetDEF-CI pushed a commit that referenced this pull request Sep 25, 2025
Problem 1:
1. when s_client->gr_instance_count > 0 the code removed info
from gr_info_queue and returned without freeing it.

Fix:
We now free info on that early return, so that leak is closed.

Problem 2. During shutdown of zebra, stale clients are scheduled for deletion
in META_QUEUE_GR. But before the META_QUEUE_GR is processed, zebra shuts down
as a result there's a leak

Fix:
Implemented synchronous free on shutdown path.

Leak in both cases:
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
    #0 0x7f48922b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f4891e23c0d in qcalloc lib/memory.c:111
    #2 0x55602360e3ac in zebra_gr_client_info_create zebra/zebra_gr.c:101
    #3 0x55602360e3ac in zread_client_capabilities zebra/zebra_gr.c:359
    #4 0x5560235f2ead in zserv_handle_commands zebra/zapi_msg.c:4226
    #5 0x556023719ef1 in zserv_process_messages zebra/zserv.c:561
    #6 0x7f4891edbc17 in event_call lib/event.c:2009
    #7 0x7f4891e017d9 in frr_run lib/libfrr.c:1252
    #8 0x5560235a63eb in main zebra/main.c:552
    #9 0x7f489190c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Pooja Jagadeesh Doijode <[email protected]>
ton31337 added a commit that referenced this pull request Sep 30, 2025
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 <[email protected]>
ton31337 added a commit that referenced this pull request Oct 1, 2025
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 <[email protected]>
ton31337 added a commit that referenced this pull request Oct 1, 2025
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 2, 2025
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 <[email protected]>
(cherry picked from commit a7fe30e)

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

Signed-off-by: Louis Scalbert <[email protected]>
Signed-off-by: Philippe Guibert <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 7, 2025
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 <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 14, 2025
We can do this now in gdb:

(rr) walk_bgp_table table
Walking BGP table at 0x55bd95ec5b70
  AFI: 3, SAFI: 5
  Version: 0
  (Two-level table: RD -> Routes)

=== RD: 10.0.0.21:2 ===

  === Dest #1: 0x55bd961a0130 ===
  Prefix: [5]:[0]:[32]:10.1.1.1
    dest->flags: 0x1 PROCESS_SCHEDULED
    --- Path #1 ---
      bgp_path_info: 0x55bd961a04b0
        peer: 0x55bd95ebdfd0 (Static announcement)
        type: 10, sub_type: 1 (STATIC)
        flags: 0x80010 VALID UNSORTED
        uptime: 764569, lock: 1
        attr: 0x55bd961a0380 (nexthop: 120.0.0.3)
        extra: 0x55bd960ac720 [has labels] [has evpn]
        next: 0x0, prev: 0x0

=== RD: 10.0.0.33:1 ===

  === Dest #2: 0x55bd95eb41e0 ===
  Prefix: [5]:[0]:[32]:10.1.1.1
    dest->flags: 0x0
    --- Path #1 ---
      bgp_path_info: 0x55bd95ea2a20
        peer: 0x55bd95ed56a0 (10.0.0.18)
        type: 10, sub_type: 0 (NORMAL)
        flags: 0x418 SELECTED VALID COUNTED
        uptime: 764568, lock: 2
        attr: 0x55bd956aa3b0 (nexthop: 120.0.0.1)
        extra: 0x55bd960a5d60 [has labels] [has evpn]
        next: 0x0, prev: 0x0

  === Dest #3: 0x55bd960aa4b0 ===
  Prefix: [5]:[0]:[128]:10:0:0:0:0:0:0:1
    dest->flags: 0x0
    --- Path #1 ---
      bgp_path_info: 0x55bd960ad190
        peer: 0x55bd95ed56a0 (10.0.0.18)
        type: 10, sub_type: 0 (NORMAL)
        flags: 0x418 SELECTED VALID COUNTED
        uptime: 764569, lock: 2
        attr: 0x55bd960ad2e0 (nexthop: 120.0.0.1)
        extra: 0x55bd960aa540 [has labels] [has evpn]
        next: 0x0, prev: 0x0

=== RD: 10.0.0.37:2 ===

  === Dest #4: 0x55bd960ad930 ===
  Prefix: [5]:[0]:[32]:20.1.1.1
    dest->flags: 0x0
    --- Path #1 ---
      bgp_path_info: 0x55bd960a97b0
        peer: 0x55bd95ed56a0 (10.0.0.18)
        type: 10, sub_type: 0 (NORMAL)
        flags: 0x418 SELECTED VALID COUNTED
        uptime: 764568, lock: 2
        attr: 0x55bd960a93b0 (nexthop: 120.0.0.1)
        extra: 0x55bd960a6b30 [has labels] [has evpn]
        next: 0x0, prev: 0x0

--Type <RET> for more, q to quit, c to continue without paging--
=== RD: 10.0.0.41:3 ===

  === Dest #5: 0x55bd960a9c30 ===
  Prefix: [5]:[0]:[32]:30.1.1.1
    dest->flags: 0x0
    --- Path #1 ---
      bgp_path_info: 0x55bd960a9e10
        peer: 0x55bd95ed56a0 (10.0.0.18)
        type: 10, sub_type: 0 (NORMAL)
        flags: 0x418 SELECTED VALID COUNTED
        uptime: 764568, lock: 2
        attr: 0x55bd960a9cc0 (nexthop: 120.0.0.1)
        extra: 0x55bd960a9eb0 [has labels] [has evpn]
        next: 0x0, prev: 0x0

=== Summary ===
Total destinations with paths: 5
Total paths: 5

Or:

(rr) walk_bgp_table table
Walking BGP table at 0x55bd95ee53b0
  AFI: 2, SAFI: 1
  Version: 1

=== Dest #1: 0x55bd960ad4a0 ===
Prefix: IPv6:10:0:0:0:0:0:0:1/128
  dest->flags: 0x1 PROCESS_SCHEDULED
  --- Path #1 ---
    bgp_path_info: 0x55bd960a5eb0
      peer: 0x55bd95ef92c0 (fd00:0:0:5::2)
      type: 10, sub_type: 0 (NORMAL)
      flags: 0x80400 COUNTED UNSORTED
      uptime: 764569, lock: 1
      attr: 0x55bd9619fb20 (nexthop: 0.0.0.0)
      extra: 0x55bd95ef31d0
      next: 0x55bd960abe30, prev: 0x0
  --- Path #2 ---
    bgp_path_info: 0x55bd960abe30
      peer: 0x55bd95ed56a0 (10.0.0.18)
      type: 10, sub_type: 5 (IMPORTED)
      flags: 0x4018 SELECTED VALID ANNC_NH_SELF
      uptime: 764569, lock: 1
      attr: 0x55bd960ad530 (nexthop: 120.0.0.1)
      extra: 0x55bd960abed0 [has labels] [has vrfleak]
      next: 0x0, prev: 0x55bd960a5eb0

=== Summary ===
Total destinations with paths: 1
Total paths: 2

People might find this useful.

Signed-off-by: Donald Sharp <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Oct 15, 2025
On one interface without any mld/pim/igmp configuration, set the command:
`ip igmp require-router-alert` or `ipv6 mld require-router-alert`.
It will crash for empty `pim_ifp`.

```
 #0  0x000055cd72861d40 in lib_interface_gmp_require_router_alert_modify (args=0x7ffec1894e70) at ../pimd/pim_nb_config.c:4768
 #1  0x00007f5cdcda137b in nb_callback_modify (context=0x55cd74647a10, nb_node=0x55cd7441c970, event=NB_EV_APPLY, dnode=0x55cd74646350, resource=0x55cd746470c8,
     errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1598
 #2  0x00007f5cdcda20b7 in nb_callback_configuration (context=0x55cd74647a10, event=NB_EV_APPLY, change=0x55cd74647090, errmsg=0x7ffec1895460 "", errmsg_len=8192)
     at ../lib/northbound.c:1962
 #3  0x00007f5cdcda261f in nb_transaction_process (event=NB_EV_APPLY, transaction=0x55cd74647a10, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:2091
 #4  0x00007f5cdcda0cee in nb_candidate_commit_apply (transaction=0x55cd74647a10, save_transaction=true, transaction_id=0x0, errmsg=0x7ffec1895460 "", errmsg_len=8192)
     at ../lib/northbound.c:1409
 #5  0x00007f5cdcda0e76 in nb_candidate_commit (context=..., candidate=0x55cd7439d960, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7ffec1895460 "",
     errmsg_len=8192) at ../lib/northbound.c:1449
 #6  0x00007f5cdcda78aa in nb_cli_classic_commit (vty=0x55cd74639b60) at ../lib/northbound_cli.c:57
 #7  0x00007f5cdcda7ea5 in nb_cli_apply_changes_internal (vty=0x55cd74639b60,
     xpath_base=0x7ffec18994f0 "/frr-interface:lib/interface[name='xx']/frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']", clear_pending=false)
     at ../lib/northbound_cli.c:195
 #8  0x00007f5cdcda8196 in _nb_cli_apply_changes (vty=0x55cd74639b60, xpath_base=0x7ffec1899940 "./frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']",
     clear_pending=false) at ../lib/northbound_cli.c:251
 ```

Signed-off-by: anlan_cs <[email protected]>
ton31337 pushed a commit that referenced this pull request Oct 24, 2025
On one interface without any mld/pim/igmp configuration, set the command:
`ip igmp require-router-alert` or `ipv6 mld require-router-alert`.
It will crash for empty `pim_ifp`.

```
 #0  0x000055cd72861d40 in lib_interface_gmp_require_router_alert_modify (args=0x7ffec1894e70) at ../pimd/pim_nb_config.c:4768
 #1  0x00007f5cdcda137b in nb_callback_modify (context=0x55cd74647a10, nb_node=0x55cd7441c970, event=NB_EV_APPLY, dnode=0x55cd74646350, resource=0x55cd746470c8,
     errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:1598
 #2  0x00007f5cdcda20b7 in nb_callback_configuration (context=0x55cd74647a10, event=NB_EV_APPLY, change=0x55cd74647090, errmsg=0x7ffec1895460 "", errmsg_len=8192)
     at ../lib/northbound.c:1962
 #3  0x00007f5cdcda261f in nb_transaction_process (event=NB_EV_APPLY, transaction=0x55cd74647a10, errmsg=0x7ffec1895460 "", errmsg_len=8192) at ../lib/northbound.c:2091
 #4  0x00007f5cdcda0cee in nb_candidate_commit_apply (transaction=0x55cd74647a10, save_transaction=true, transaction_id=0x0, errmsg=0x7ffec1895460 "", errmsg_len=8192)
     at ../lib/northbound.c:1409
 #5  0x00007f5cdcda0e76 in nb_candidate_commit (context=..., candidate=0x55cd7439d960, save_transaction=true, comment=0x0, transaction_id=0x0, errmsg=0x7ffec1895460 "",
     errmsg_len=8192) at ../lib/northbound.c:1449
 #6  0x00007f5cdcda78aa in nb_cli_classic_commit (vty=0x55cd74639b60) at ../lib/northbound_cli.c:57
 #7  0x00007f5cdcda7ea5 in nb_cli_apply_changes_internal (vty=0x55cd74639b60,
     xpath_base=0x7ffec18994f0 "/frr-interface:lib/interface[name='xx']/frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']", clear_pending=false)
     at ../lib/northbound_cli.c:195
 #8  0x00007f5cdcda8196 in _nb_cli_apply_changes (vty=0x55cd74639b60, xpath_base=0x7ffec1899940 "./frr-gmp:gmp/address-family[address-family='frr-routing:ipv4']",
     clear_pending=false) at ../lib/northbound_cli.c:251
 ```

Signed-off-by: anlan_cs <[email protected]>
(cherry picked from commit 7491c07)
NetDEF-CI pushed a commit that referenced this pull request Jan 6, 2026
Error:

    ERROR: AddressSanitizer: heap-use-after-free on address 0x6070000ef8a0 at pc 0x555df66ba094 bp 0x7ffc13d67240 sp 0x7ffc13d67238
    READ of size 4 at 0x6070000ef8a0 thread T0
        #0 0x555df66ba093 in zebra_gr_delete_stale_route_table_afi zebra/zebra_gr.c:514
        #1 0x7fd33d6db06e in event_call lib/event.c:2013
        #2 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
        #3 0x555df66531ec in main zebra/main.c:552
        #4 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #5 0x7fd33d10c304 in __libc_start_main_impl ../csu/libc-start.c:360
        #6 0x555df6626b40 in _start (/usr/lib/frr/zebra+0x1a1b40)

    0x6070000ef8a0 is located 0 bytes inside of 72-byte region [0x6070000ef8a0,0x6070000ef8e8)
    freed by thread T0 here:
        #0 0x7fd33dab76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
        #1 0x7fd33d622cd5 in qfree lib/memory.c:136
        #2 0x555df66b9e5f in zebra_gr_client_info_delete zebra/zebra_gr.c:130
        #3 0x555df66bc66f in zread_client_capabilities zebra/zebra_gr.c:355
        #4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228
        #5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565
        #6 0x7fd33d6db06e in event_call lib/event.c:2013
        #7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
        #8 0x555df66531ec in main zebra/main.c:552
        #9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

    previously allocated by thread T0 here:
        #0 0x7fd33dab83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
        #1 0x7fd33d6223e2 in qcalloc lib/memory.c:111
        #2 0x555df66bbace in zebra_gr_client_info_create zebra/zebra_gr.c:101
        #3 0x555df66bbace in zread_client_capabilities zebra/zebra_gr.c:360
        #4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228
        #5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565
        #6 0x7fd33d6db06e in event_call lib/event.c:2013
        #7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257
        #8 0x555df66531ec in main zebra/main.c:552
        #9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Pooja Jagadeesh Doijode <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jan 13, 2026
The following crash happens, when moving from level-2 to level-1 an isis
flex-algorithm configuration

> warning: 44     ./nptl/pthread_kill.c: No such file or directory
> [Current thread is 1 (Thread 0x7108d4cb2980 (LWP 1023))]
> (gdb) bt
> #0  __pthread_kill_implementation (no_tid=0, signo=11,
>     threadid=<optimized out>) at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=<optimized out>)
>     at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
>     at ./nptl/pthread_kill.c:89
> #3  0x00007108d3e4527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x00007108d4b44926 in core_handler (signo=11, siginfo=0x7ffe7c10fb30,
>     context=0x7ffe7c10fa00)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:248
> #5  <signal handler called>
> #6  0x00005b5d803bf07b in isis_spf_invalidate_routes (tree=0x0)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2118
> #7  0x00005b5d803fb23e in isis_area_invalidate_routes (area=0x5b5db8d5be40,
>     levels=1)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isisd.c:3152
> #8  0x00005b5d803bf280 in isis_run_spf_cb (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2165
> #9  0x00007108d4b5ff7f in event_call (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:2011
> #10 0x00007108d4adb761 in frr_run (master=0x5b5db7f7ca40)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1219
> #11 0x00005b5d8038333a in main (argc=5, argv=0x7ffe7c1103d8,
> --Type <RET> for more, q to quit, c to continue without paging--
>     envp=0x7ffe7c110408)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:360
> (gdb)

Fix this by adding protection before invalidating all routes.

Signed-off-by: Philippe Guibert <[email protected]>
NetDEF-CI pushed a commit that referenced this pull request Jan 13, 2026
The following crash happens, when moving from level-2 to level-1 an isis
flex-algorithm configuration

> warning: 44     ./nptl/pthread_kill.c: No such file or directory
> [Current thread is 1 (Thread 0x7108d4cb2980 (LWP 1023))]
> (gdb) bt
> #0  __pthread_kill_implementation (no_tid=0, signo=11,
>     threadid=<optimized out>) at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=<optimized out>)
>     at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
>     at ./nptl/pthread_kill.c:89
> #3  0x00007108d3e4527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x00007108d4b44926 in core_handler (signo=11, siginfo=0x7ffe7c10fb30,
>     context=0x7ffe7c10fa00)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:248
> #5  <signal handler called>
> #6  0x00005b5d803bf07b in isis_spf_invalidate_routes (tree=0x0)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2118
> #7  0x00005b5d803fb23e in isis_area_invalidate_routes (area=0x5b5db8d5be40,
>     levels=1)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isisd.c:3152
> #8  0x00005b5d803bf280 in isis_run_spf_cb (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2165
> #9  0x00007108d4b5ff7f in event_call (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:2011
> #10 0x00007108d4adb761 in frr_run (master=0x5b5db7f7ca40)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1219
> #11 0x00005b5d8038333a in main (argc=5, argv=0x7ffe7c1103d8,
> --Type <RET> for more, q to quit, c to continue without paging--
>     envp=0x7ffe7c110408)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:360
> (gdb)

Fix this by adding protection before invalidating all routes.

Signed-off-by: Philippe Guibert <[email protected]>
(cherry picked from commit 65269be)
NetDEF-CI pushed a commit that referenced this pull request Jan 13, 2026
The following crash happens, when moving from level-2 to level-1 an isis
flex-algorithm configuration

> warning: 44     ./nptl/pthread_kill.c: No such file or directory
> [Current thread is 1 (Thread 0x7108d4cb2980 (LWP 1023))]
> (gdb) bt
> #0  __pthread_kill_implementation (no_tid=0, signo=11,
>     threadid=<optimized out>) at ./nptl/pthread_kill.c:44
> #1  __pthread_kill_internal (signo=11, threadid=<optimized out>)
>     at ./nptl/pthread_kill.c:78
> #2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
>     at ./nptl/pthread_kill.c:89
> #3  0x00007108d3e4527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4  0x00007108d4b44926 in core_handler (signo=11, siginfo=0x7ffe7c10fb30,
>     context=0x7ffe7c10fa00)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:248
> #5  <signal handler called>
> #6  0x00005b5d803bf07b in isis_spf_invalidate_routes (tree=0x0)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2118
> #7  0x00005b5d803fb23e in isis_area_invalidate_routes (area=0x5b5db8d5be40,
>     levels=1)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isisd.c:3152
> #8  0x00005b5d803bf280 in isis_run_spf_cb (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2165
> #9  0x00007108d4b5ff7f in event_call (thread=0x7ffe7c110180)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:2011
> #10 0x00007108d4adb761 in frr_run (master=0x5b5db7f7ca40)
>     at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1219
> #11 0x00005b5d8038333a in main (argc=5, argv=0x7ffe7c1103d8,
> --Type <RET> for more, q to quit, c to continue without paging--
>     envp=0x7ffe7c110408)
>     at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:360
> (gdb)

Fix this by adding protection before invalidating all routes.

Signed-off-by: Philippe Guibert <[email protected]>
(cherry picked from commit 65269be)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants