bgpd, lib: fix bgpd core on startup #12
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This was referenced Sep 5, 2017
rwestphal
referenced
this pull request
in opensourcerouting/frr
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 <renato@opensourcerouting.org>
rwestphal
referenced
this pull request
in opensourcerouting/frr
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 <renato@opensourcerouting.org>
Merged
qlyoung
pushed a commit
to qlyoung/frr
that referenced
this pull request
Aug 8, 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 FRRouting#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503 FRRouting#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294 FRRouting#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606 FRRouting#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011 FRRouting#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 <renato@opensourcerouting.org>
riw777
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: #5025 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
mjstapp
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: #5025 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
SumitAgarwal123
pushed a commit
to SumitAgarwal123/frr
that referenced
this pull request
Nov 19, 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 FRRouting#1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230 error 09-Oct-2019 19:28:33 FRRouting#2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520 error 09-Oct-2019 19:28:33 FRRouting#3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071 error 09-Oct-2019 19:28:33 FRRouting#4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736 error 09-Oct-2019 19:28:33 FRRouting#5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237 error 09-Oct-2019 19:28:33 FRRouting#6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315 error 09-Oct-2019 19:28:33 FRRouting#7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598 error 09-Oct-2019 19:28:33 FRRouting#8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274 error 09-Oct-2019 19:28:33 FRRouting#9 0x6b9f54 in thread_call lib/thread.c:1531 error 09-Oct-2019 19:28:33 FRRouting#10 0x657037 in frr_run lib/libfrr.c:1052 error 09-Oct-2019 19:28:33 FRRouting#11 0x42d268 in main bgpd/bgp_main.c:486 error 09-Oct-2019 19:28:33 FRRouting#12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) error 09-Oct-2019 19:28:33 FRRouting#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 <sharpd@cumulusnetworks.com>
jpetersonssr
added a commit
to jpetersonssr/frr
that referenced
this pull request
Jul 24, 2025
…show-rib-count-55 increase show rib count frr 7.5.1
kniteli
pushed a commit
to kniteli/frr
that referenced
this pull request
Jul 24, 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 > FRRouting#1 0x556cdc178f55 in dplane_ctx_ns_init zebra/zebra_dplane.c:3410 > FRRouting#2 0x556cdc17b829 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3759 > FRRouting#3 0x556cdc18095f in dplane_nexthop_update_internal zebra/zebra_dplane.c:4566 > FRRouting#4 0x556cdc1813f1 in dplane_nexthop_delete zebra/zebra_dplane.c:4793 > FRRouting#5 0x556cdc229234 in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3484 > FRRouting#6 0x556cdc21f8fe in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1804 > FRRouting#7 0x556cdc24b05a in route_entry_update_nhe zebra/zebra_rib.c:456 > FRRouting#8 0x556cdc255083 in rib_re_nhg_free zebra/zebra_rib.c:2633 > FRRouting#9 0x556cdc25e3bb in rib_unlink zebra/zebra_rib.c:4049 > FRRouting#10 0x556cdc24c9b0 in zebra_rtable_node_cleanup zebra/zebra_rib.c:903 > FRRouting#11 0x7fb25c173144 in route_node_free lib/table.c:75 > FRRouting#12 0x7fb25c17337f in route_table_free lib/table.c:111 > FRRouting#13 0x7fb25c172fe4 in route_table_finish lib/table.c:46 > FRRouting#14 0x556cdc266f62 in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#15 0x556cdc2673ef in zebra_router_terminate zebra/zebra_router.c:243 > FRRouting#16 0x556cdc10638b in zebra_finalize zebra/main.c:240 > FRRouting#17 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#18 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#19 0x556cdc106deb in main zebra/main.c:543 > FRRouting#20 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#21 0x7fb25ba29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#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 > FRRouting#1 0x7fb25c0790e3 in qfree lib/memory.c:131 > FRRouting#2 0x556cdc22d9c9 in zebra_ns_delete zebra/zebra_ns.c:261 > FRRouting#3 0x7fb25c0ac400 in ns_delete lib/netns_linux.c:319 > FRRouting#4 0x556cdc28026a in zebra_vrf_delete zebra/zebra_vrf.c:343 > FRRouting#5 0x7fb25c197443 in vrf_delete lib/vrf.c:282 > FRRouting#6 0x7fb25c1987e8 in vrf_terminate_single lib/vrf.c:601 > FRRouting#7 0x7fb25c197a7a in vrf_iterate lib/vrf.c:394 > FRRouting#8 0x7fb25c198834 in vrf_terminate lib/vrf.c:609 > FRRouting#9 0x556cdc106345 in zebra_finalize zebra/main.c:223 > FRRouting#10 0x7fb25c18e012 in event_call lib/event.c:2019 > FRRouting#11 0x7fb25c04afc6 in frr_run lib/libfrr.c:1247 > FRRouting#12 0x556cdc106deb in main zebra/main.c:543 > FRRouting#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 > FRRouting#1 0x7fb25c078f91 in qcalloc lib/memory.c:106 > FRRouting#2 0x556cdc22d6a1 in zebra_ns_new zebra/zebra_ns.c:231 > FRRouting#3 0x556cdc22e30b in zebra_ns_init zebra/zebra_ns.c:429 > FRRouting#4 0x556cdc106cec in main zebra/main.c:480 > FRRouting#5 0x7fb25ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-use-after-free zebra/zebra_dplane.c:3394 in ctx_info_from_zns Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
kniteli
pushed a commit
to kniteli/frr
that referenced
this pull request
Jul 24, 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 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=130889386464320) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=130889386464320, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x0000770b0f042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x0000770b0f507846 in core_handler (signo=11, siginfo=0x7ffd4f7ec9f0, context=0x7ffd4f7ec8c0) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262 > FRRouting#5 <signal handler called> > FRRouting#6 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339 > FRRouting#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 > FRRouting#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 > FRRouting#9 0x00005f75d5434652 in nhrp_peer_forward (p=0x5f75f2605f30, pp=0x7ffd4f7ed8c0) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1050 > FRRouting#10 0x00005f75d54356cb in nhrp_peer_recv (p=0x5f75f2605f30, zb=0x5f75f2627da0) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_peer.c:1341 > FRRouting#11 0x00005f75d5430d8e in nhrp_packet_recvraw (t=0x7ffd4f7ede80) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_packet.c:332 > FRRouting#12 0x0000770b0f521188 in thread_call (thread=0x7ffd4f7ede80) > at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825 > FRRouting#13 0x0000770b0f4b7737 in frr_run (master=0x5f75f2440570) > at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155 > FRRouting#14 0x00005f75d542d2b4 in main (argc=3, argv=0x7ffd4f7ee0b8) > at /build/make-pkg/output/_packages/cp-routing/src/nhrpd/nhrp_main.c:317 The incoming nhrp packet is too short, and the call to sockunion_set() uses a 0x0 memory zone, because the whole nhrp packet has been parsed, and the zbuf length used was 0. Fix this by detecting the zbuf remaining length before calling sockunion_set. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
kniteli
pushed a commit
to kniteli/frr
that referenced
this pull request
Jul 24, 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
FRRouting#1 0x7f34c241b45a in qcalloc lib/memory.c:111
FRRouting#2 0x7f34c247b1da in prefix_new lib/prefix.c:1192
FRRouting#3 0x55e0992e2041 in peer_group_listen_range_add bgpd/bgpd.c:3258
FRRouting#4 0x55e099282694 in bgp_listen_range bgpd/bgp_vty.c:4848
FRRouting#5 0x7f34c2397bc0 in cmd_execute_command_real lib/command.c:1011
FRRouting#6 0x7f34c2397edf in cmd_execute_command lib/command.c:1070
FRRouting#7 0x7f34c239840b in cmd_execute lib/command.c:1236
FRRouting#8 0x7f34c24e204e in vty_command lib/vty.c:626
FRRouting#9 0x7f34c24e259b in vty_execute lib/vty.c:1389
FRRouting#10 0x7f34c24e5f97 in vtysh_read lib/vty.c:2408
FRRouting#11 0x7f34c24d2958 in event_call lib/event.c:2005
FRRouting#12 0x7f34c23fc4e0 in frr_run lib/libfrr.c:1247
FRRouting#13 0x55e0990949ff in main bgpd/bgp_main.c:565
FRRouting#14 0x7f34c1e2c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 1 allocation(s).
***********************************************************************************
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Jul 31, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 11, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 12, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 12, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 12, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 12, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 13, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 20, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 20, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 20, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 20, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 21, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 22, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 22, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 29, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Aug 29, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 2, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 8, 2025
The following crash has happened. > #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:44 > FRRouting#1 __pthread_kill_internal (signo=11, threadid=134363256068544) at ./nptl/pthread_kill.c:78 > FRRouting#2 __GI___pthread_kill (threadid=134363256068544, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 > FRRouting#3 0x00007a33e1c42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 > FRRouting#4 0x00007a33e210feca in core_handler (signo=11, siginfo=0x7ffd4a405130, context=<optimized out>) at lib/sigevent.c:268 > FRRouting#5 <signal handler called> > FRRouting#6 vpn_leak_to_vrf_update_onevrf (to_bgp=0x5a70a945d9b0, from_bgp=0x5a70a945d9b0, path_vpn=0x5a70a9488b50, prd=0x0, from=0x5a70a9482350) at bgpd/bgp_mplsvpn.c:2256 > FRRouting#7 0x00005a7093ca627c in vpn_leak_to_vrf_update_all (to_bgp=to_bgp@entry=0x5a70a945d9b0, vpn_from=vpn_from@entry=0x5a70a945d9b0, afi=afi@entry=AFI_IP) at bgpd/bgp_mplsvpn.c:2839 > FRRouting#8 0x00005a7093ca789d in vpn_leak_postchange (bgp_vrf=0x5a70a945d9b0, bgp_vpn=0x5a70a945d9b0, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_FROMVPN) at ./bgpd/bgp_mplsvpn.h:270 > FRRouting#9 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:4001 > FRRouting#10 0x00007a33e2123366 in event_call (thread=thread@entry=0x7ffd4a405a50) at lib/event.c:2005 > FRRouting#11 0x00007a33e20c3828 in frr_run (loop=0x5a70a8c0ff90) at lib/libfrr.c:1252 > FRRouting#12 0x00005a7093c45122 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:565 prefix attached to pdest is null. Protect it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 9, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 9, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 10, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 10, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 11, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 11, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
added a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 11, 2025
The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
pguibert6WIND
pushed a commit
to pguibert6WIND/frr
that referenced
this pull request
Sep 11, 2025
The topotest bgp_srv6_sid_explicit generates the crash dump:
ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0)
The signal is caused by a READ memory access.
#0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264
FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611
FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807
FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314
FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67
FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115
FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245
FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313
FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425
FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521
FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011
FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219
FRRouting#12 0x55a58a73079d in main zebra/main.c:550
FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360
FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4)
Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #11
Edit: already in master
Signed-off-by: Quentin Young qlyoung@cumulusnetworks.com