-
Notifications
You must be signed in to change notification settings - Fork 1.4k
ldpd: json support for show commands #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
|
|
|
|
@rwestphal can you take a look at this one |
A few additional issues: 1 - There's no "json" option for the L2VPN commands (which are only two by now). 2 - This is the output of "show mpls ldp neighbor json" on my dual-stack ldpd test network:
We are not showing the address-family of the adjacencies. I guess we could change this:
To this (*):
* I introduced one targeted adjacency in the output to show how it would fit in there. 3 - In the same command above, I think we can remove this line from the json output:
ldpd supports only this mode of operation (which is not really a limitation), so it's a moot piece of information. 4 - The "show mpls ldp interface json" command is not showing all interface/address-family combinations:
5 - ldpd segfaults on "show mpls ldp discovery json" if we have any targeted neighbor to display:
|
For
RIght now with that file checked in it is very easy to overlook the fact that it should not be edited. I just tried |
For |
Yes, I thought about creating a make target for the auto-generated files. But the problem with that is that it would add another dependency to build FRR, which can be a problem on some platforms. So, since ldp_vty.xml is barely changed, I think doing that is not worth the hassle. Regarding the "{}" notation, indeed. xml2cli.pl was written a few years ago and I need to extended it to make use of this new feature. But having a new command just to add the "json" option should not be a "show stopper", it's only dumb and inefficient. I should have a patch for this in a few hours. |
For |
For |
For |
Ack |
@rwestphal can you send me your dual-stack config with target neighbors? |
Sure, will send by email now. |
Wow this interface is tough for having multiple conversations...I think if you start a review you can click on "+" to leave a comment and then we can reply to each other. That may be a little easier for both of us :) Agreed xml2cli.pl isn't a show stopper but if it is something you think you can knock out really quick I'll hold off and wait for it. If not I'm fine with it putting in the extra DEFUNs. Having xml2cli.pl run as part of the build and removing ldp_vty_cmds.c from the repo seems like a must though. We already depend on PERL for building (extract.pl) so it wouldn't be adding a new dependancy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, just clicked on "Add your review". Not really sure if this changes anything regarding the interface for conversation.
Regarding xml2cli.pl. please give me 10 minutes and I should have something ready.
@dwalton76 I've just sent to the list a patch to extend xml2cli.pl as you requested. Now, for each command, you need to modify the XML file as follows:
Then the new output of the script should be exactly what you want:
|
@dwalton76 and @rwestphal What can I do to help drive this to completion? |
sorry, will pick this back up either this week or next and address all of the points that Renato raised |
I'd say that 95% of the work is already done. @dwalton76, if you don't mind I can update your patch to address the points I mentioned earlier, it's only a few things that need to be changed. |
@rwestphal that is fine with me. Thanks! |
If the 'show bgp ipv4 vpn' command is interrupted during the dump of the whole entries, then a heap use after free may appear. > May 15 16:08:14 vRR-DUT bgpd[1647]: [N9HHH-F8H1M] %ADJCHANGE: neighbor 3.3.1.232(taastpap-scale-1) in vrf default Up > May 15 16:08:14 vRR-DUT bgpd[1647]: [GJPH1-W8PZV] Resetting peer 3.3.1.232 due to change in addpath config > May 15 16:08:14 vRR-DUT bgpd[1647]: [YAF85-253AP][EC 100663299] buffer_flush_available: write error on fd 70: Broken pipe > May 15 16:08:14 vRR-DUT bgpd[1647]: [THHDB-YPEY6][EC 100663299] vtysh_flush: write error to fd 70, closing > May 15 16:08:14 vRR-DUT bgpd[1647]: ================================================================= > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b001d65238 at pc 0x7efd46b83fa0 bp 0x7ffd4d598> > May 15 16:08:14 vRR-DUT bgpd[1647]: READ of size 1 at 0x62b001d65238 thread T0 > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd46b83f9f in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46429e3f in __libc_start_main_impl ../csu/libc-start.c:392 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x5570c06bc384 in _start (/usr/bin/bgpd+0x272384) > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x62b001d65238 is located 56 bytes inside of 26536-byte region [0x62b001d65200,0x62b001d6b9a8) > May 15 16:08:14 vRR-DUT bgpd[1647]: freed by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f930 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f930) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b92467 in vty_close (/lib/x86_64-linux-gnu/libfrr.so.0+0x392467) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8fd4c (/lib/x86_64-linux-gnu/libfrr.so.0+0x38fd4c) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b83f60 in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f60) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#20 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#21 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: previously allocated by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f7de in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7de) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b8c5ba in vty_new (/lib/x86_64-linux-gnu/libfrr.so.0+0x38c5ba) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8f0fe (/lib/x86_64-linux-gnu/libfrr.so.0+0x38f0fe) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: SUMMARY: AddressSanitizer: heap-use-after-free (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) in vty_out > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow bytes around the buggy address: > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a49f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: =>0x0c56803a4a40: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow byte legend (one shadow byte represents 8 application bytes): > May 15 16:08:14 vRR-DUT bgpd[1647]: Addressable: 00 > May 15 16:08:14 vRR-DUT bgpd[1647]: Partially addressable: 01 02 03 04 05 06 07 > May 15 16:08:14 vRR-DUT bgpd[1647]: Heap left redzone: fa > May 15 16:08:14 vRR-DUT bgpd[1647]: Freed heap region: fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack left redzone: f1 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack mid redzone: f2 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack right redzone: f3 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack after return: f5 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack use after scope: f8 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global redzone: f9 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global init order: f6 > May 15 16:08:14 vRR-DUT bgpd[1647]: Poisoned by user: f7 > May 15 16:08:14 vRR-DUT bgpd[1647]: Container overflow: fc > May 15 16:08:14 vRR-DUT bgpd[1647]: Array cookie: ac > May 15 16:08:14 vRR-DUT bgpd[1647]: Intra object redzone: bb > May 15 16:08:14 vRR-DUT bgpd[1647]: ASan internal: fe > May 15 16:08:14 vRR-DUT bgpd[1647]: Left alloca redzone: ca > May 15 16:08:14 vRR-DUT bgpd[1647]: Right alloca redzone: cb > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow gap: cc > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ABORTING The vty_out() function detects a BROKEN PIPE error durint the call of vty_flush(), and closes the vty pointer. Consequently, the next vty_out() calls may use an invalid vty pointer. Propose to delay the removal of the vty pointer at the next scheduling. Until that event, keep the vty structure at CLOSE state. The show function will eventually detect the invalid vty status, and will anticipate the end of the show command. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If the 'show bgp ipv4 vpn' command is interrupted during the dump of the whole entries, then a heap use after free may appear. > May 15 16:08:14 vRR-DUT bgpd[1647]: [N9HHH-F8H1M] %ADJCHANGE: neighbor 3.3.1.232(taastpap-scale-1) in vrf default Up > May 15 16:08:14 vRR-DUT bgpd[1647]: [GJPH1-W8PZV] Resetting peer 3.3.1.232 due to change in addpath config > May 15 16:08:14 vRR-DUT bgpd[1647]: [YAF85-253AP][EC 100663299] buffer_flush_available: write error on fd 70: Broken pipe > May 15 16:08:14 vRR-DUT bgpd[1647]: [THHDB-YPEY6][EC 100663299] vtysh_flush: write error to fd 70, closing > May 15 16:08:14 vRR-DUT bgpd[1647]: ================================================================= > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b001d65238 at pc 0x7efd46b83fa0 bp 0x7ffd4d598> > May 15 16:08:14 vRR-DUT bgpd[1647]: READ of size 1 at 0x62b001d65238 thread T0 > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd46b83f9f in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46429e3f in __libc_start_main_impl ../csu/libc-start.c:392 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x5570c06bc384 in _start (/usr/bin/bgpd+0x272384) > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x62b001d65238 is located 56 bytes inside of 26536-byte region [0x62b001d65200,0x62b001d6b9a8) > May 15 16:08:14 vRR-DUT bgpd[1647]: freed by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f930 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f930) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b92467 in vty_close (/lib/x86_64-linux-gnu/libfrr.so.0+0x392467) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8fd4c (/lib/x86_64-linux-gnu/libfrr.so.0+0x38fd4c) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b83f60 in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f60) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#20 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#21 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: previously allocated by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f7de in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7de) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b8c5ba in vty_new (/lib/x86_64-linux-gnu/libfrr.so.0+0x38c5ba) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8f0fe (/lib/x86_64-linux-gnu/libfrr.so.0+0x38f0fe) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: SUMMARY: AddressSanitizer: heap-use-after-free (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) in vty_out > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow bytes around the buggy address: > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a49f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: =>0x0c56803a4a40: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow byte legend (one shadow byte represents 8 application bytes): > May 15 16:08:14 vRR-DUT bgpd[1647]: Addressable: 00 > May 15 16:08:14 vRR-DUT bgpd[1647]: Partially addressable: 01 02 03 04 05 06 07 > May 15 16:08:14 vRR-DUT bgpd[1647]: Heap left redzone: fa > May 15 16:08:14 vRR-DUT bgpd[1647]: Freed heap region: fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack left redzone: f1 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack mid redzone: f2 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack right redzone: f3 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack after return: f5 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack use after scope: f8 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global redzone: f9 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global init order: f6 > May 15 16:08:14 vRR-DUT bgpd[1647]: Poisoned by user: f7 > May 15 16:08:14 vRR-DUT bgpd[1647]: Container overflow: fc > May 15 16:08:14 vRR-DUT bgpd[1647]: Array cookie: ac > May 15 16:08:14 vRR-DUT bgpd[1647]: Intra object redzone: bb > May 15 16:08:14 vRR-DUT bgpd[1647]: ASan internal: fe > May 15 16:08:14 vRR-DUT bgpd[1647]: Left alloca redzone: ca > May 15 16:08:14 vRR-DUT bgpd[1647]: Right alloca redzone: cb > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow gap: cc > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ABORTING The vty_out() function detects a BROKEN PIPE error durint the call of vty_flush(), and closes the vty pointer. Consequently, the next vty_out() calls may use an invalid vty pointer. Propose to delay the removal of the vty pointer at the next scheduling. Until that event, keep the vty structure at CLOSE state. The show function will eventually detect the invalid vty status, and will anticipate the end of the show command. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
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>
If the 'show bgp ipv4 vpn' command is interrupted during the dump of the whole entries, then a heap use after free may appear. > May 15 16:08:14 vRR-DUT bgpd[1647]: [N9HHH-F8H1M] %ADJCHANGE: neighbor 3.3.1.232(taastpap-scale-1) in vrf default Up > May 15 16:08:14 vRR-DUT bgpd[1647]: [GJPH1-W8PZV] Resetting peer 3.3.1.232 due to change in addpath config > May 15 16:08:14 vRR-DUT bgpd[1647]: [YAF85-253AP][EC 100663299] buffer_flush_available: write error on fd 70: Broken pipe > May 15 16:08:14 vRR-DUT bgpd[1647]: [THHDB-YPEY6][EC 100663299] vtysh_flush: write error to fd 70, closing > May 15 16:08:14 vRR-DUT bgpd[1647]: ================================================================= > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b001d65238 at pc 0x7efd46b83fa0 bp 0x7ffd4d598> > May 15 16:08:14 vRR-DUT bgpd[1647]: READ of size 1 at 0x62b001d65238 thread T0 > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd46b83f9f in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46429e3f in __libc_start_main_impl ../csu/libc-start.c:392 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x5570c06bc384 in _start (/usr/bin/bgpd+0x272384) > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x62b001d65238 is located 56 bytes inside of 26536-byte region [0x62b001d65200,0x62b001d6b9a8) > May 15 16:08:14 vRR-DUT bgpd[1647]: freed by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f930 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f930) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b92467 in vty_close (/lib/x86_64-linux-gnu/libfrr.so.0+0x392467) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8fd4c (/lib/x86_64-linux-gnu/libfrr.so.0+0x38fd4c) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b83f60 in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f60) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#20 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#21 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: previously allocated by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f7de in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7de) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b8c5ba in vty_new (/lib/x86_64-linux-gnu/libfrr.so.0+0x38c5ba) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8f0fe (/lib/x86_64-linux-gnu/libfrr.so.0+0x38f0fe) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: SUMMARY: AddressSanitizer: heap-use-after-free (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) in vty_out > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow bytes around the buggy address: > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a49f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: =>0x0c56803a4a40: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow byte legend (one shadow byte represents 8 application bytes): > May 15 16:08:14 vRR-DUT bgpd[1647]: Addressable: 00 > May 15 16:08:14 vRR-DUT bgpd[1647]: Partially addressable: 01 02 03 04 05 06 07 > May 15 16:08:14 vRR-DUT bgpd[1647]: Heap left redzone: fa > May 15 16:08:14 vRR-DUT bgpd[1647]: Freed heap region: fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack left redzone: f1 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack mid redzone: f2 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack right redzone: f3 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack after return: f5 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack use after scope: f8 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global redzone: f9 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global init order: f6 > May 15 16:08:14 vRR-DUT bgpd[1647]: Poisoned by user: f7 > May 15 16:08:14 vRR-DUT bgpd[1647]: Container overflow: fc > May 15 16:08:14 vRR-DUT bgpd[1647]: Array cookie: ac > May 15 16:08:14 vRR-DUT bgpd[1647]: Intra object redzone: bb > May 15 16:08:14 vRR-DUT bgpd[1647]: ASan internal: fe > May 15 16:08:14 vRR-DUT bgpd[1647]: Left alloca redzone: ca > May 15 16:08:14 vRR-DUT bgpd[1647]: Right alloca redzone: cb > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow gap: cc > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ABORTING The vty_out() function detects a BROKEN PIPE error durint the call of vty_flush(), and closes the vty pointer. Consequently, the next vty_out() calls may use an invalid vty pointer. Propose to delay the removal of the vty pointer at the next scheduling. Until that event, keep the vty structure at CLOSE state. The show function will eventually detect the invalid vty status, and will anticipate the end of the show command. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If the 'show bgp ipv4 vpn' command is interrupted during the dump of the whole entries, then a heap use after free may appear. > May 15 16:08:14 vRR-DUT bgpd[1647]: [N9HHH-F8H1M] %ADJCHANGE: neighbor 3.3.1.232(taastpap-scale-1) in vrf default Up > May 15 16:08:14 vRR-DUT bgpd[1647]: [GJPH1-W8PZV] Resetting peer 3.3.1.232 due to change in addpath config > May 15 16:08:14 vRR-DUT bgpd[1647]: [YAF85-253AP][EC 100663299] buffer_flush_available: write error on fd 70: Broken pipe > May 15 16:08:14 vRR-DUT bgpd[1647]: [THHDB-YPEY6][EC 100663299] vtysh_flush: write error to fd 70, closing > May 15 16:08:14 vRR-DUT bgpd[1647]: ================================================================= > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b001d65238 at pc 0x7efd46b83fa0 bp 0x7ffd4d598> > May 15 16:08:14 vRR-DUT bgpd[1647]: READ of size 1 at 0x62b001d65238 thread T0 > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd46b83f9f in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46429e3f in __libc_start_main_impl ../csu/libc-start.c:392 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x5570c06bc384 in _start (/usr/bin/bgpd+0x272384) > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x62b001d65238 is located 56 bytes inside of 26536-byte region [0x62b001d65200,0x62b001d6b9a8) > May 15 16:08:14 vRR-DUT bgpd[1647]: freed by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f930 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f930) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b92467 in vty_close (/lib/x86_64-linux-gnu/libfrr.so.0+0x392467) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8fd4c (/lib/x86_64-linux-gnu/libfrr.so.0+0x38fd4c) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b83f60 in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f60) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#20 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#21 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: previously allocated by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f7de in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7de) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b8c5ba in vty_new (/lib/x86_64-linux-gnu/libfrr.so.0+0x38c5ba) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8f0fe (/lib/x86_64-linux-gnu/libfrr.so.0+0x38f0fe) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: SUMMARY: AddressSanitizer: heap-use-after-free (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) in vty_out > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow bytes around the buggy address: > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a49f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: =>0x0c56803a4a40: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow byte legend (one shadow byte represents 8 application bytes): > May 15 16:08:14 vRR-DUT bgpd[1647]: Addressable: 00 > May 15 16:08:14 vRR-DUT bgpd[1647]: Partially addressable: 01 02 03 04 05 06 07 > May 15 16:08:14 vRR-DUT bgpd[1647]: Heap left redzone: fa > May 15 16:08:14 vRR-DUT bgpd[1647]: Freed heap region: fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack left redzone: f1 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack mid redzone: f2 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack right redzone: f3 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack after return: f5 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack use after scope: f8 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global redzone: f9 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global init order: f6 > May 15 16:08:14 vRR-DUT bgpd[1647]: Poisoned by user: f7 > May 15 16:08:14 vRR-DUT bgpd[1647]: Container overflow: fc > May 15 16:08:14 vRR-DUT bgpd[1647]: Array cookie: ac > May 15 16:08:14 vRR-DUT bgpd[1647]: Intra object redzone: bb > May 15 16:08:14 vRR-DUT bgpd[1647]: ASan internal: fe > May 15 16:08:14 vRR-DUT bgpd[1647]: Left alloca redzone: ca > May 15 16:08:14 vRR-DUT bgpd[1647]: Right alloca redzone: cb > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow gap: cc > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ABORTING The vty_out() function detects a BROKEN PIPE error during the call of vtysh_flush() call, and closes the vty pointer. Consequently, the next vty_out() calls may use an invalid vty pointer. The call to vtysh_flush() has been added in a previous commit: this call does a syncronous write, which triggers the error. Propose to delay the removal of the vty pointer at the next scheduling. Until that event, keep the vty structure at CLOSE state. The show function will eventually detect the invalid vty status, and will anticipate the end of the show command. Fixes: 9112fb3 ("lib: Memory spike reduction for sh cmds at scale") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If the 'show bgp ipv4 vpn' command is interrupted during the dump of the whole entries, then a heap use after free may appear. > May 15 16:08:14 vRR-DUT bgpd[1647]: [N9HHH-F8H1M] %ADJCHANGE: neighbor 3.3.1.232(taastpap-scale-1) in vrf default Up > May 15 16:08:14 vRR-DUT bgpd[1647]: [GJPH1-W8PZV] Resetting peer 3.3.1.232 due to change in addpath config > May 15 16:08:14 vRR-DUT bgpd[1647]: [YAF85-253AP][EC 100663299] buffer_flush_available: write error on fd 70: Broken pipe > May 15 16:08:14 vRR-DUT bgpd[1647]: [THHDB-YPEY6][EC 100663299] vtysh_flush: write error to fd 70, closing > May 15 16:08:14 vRR-DUT bgpd[1647]: ================================================================= > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b001d65238 at pc 0x7efd46b83fa0 bp 0x7ffd4d598> > May 15 16:08:14 vRR-DUT bgpd[1647]: READ of size 1 at 0x62b001d65238 thread T0 > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd46b83f9f in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46429e3f in __libc_start_main_impl ../csu/libc-start.c:392 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x5570c06bc384 in _start (/usr/bin/bgpd+0x272384) > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x62b001d65238 is located 56 bytes inside of 26536-byte region [0x62b001d65200,0x62b001d6b9a8) > May 15 16:08:14 vRR-DUT bgpd[1647]: freed by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f930 in qfree (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f930) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b92467 in vty_close (/lib/x86_64-linux-gnu/libfrr.so.0+0x392467) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8fd4c (/lib/x86_64-linux-gnu/libfrr.so.0+0x38fd4c) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b83f60 in vty_out (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f60) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x5570c0a4e7d2 in aspath_print_vty /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_aspath.c:2308 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c08a8ce6 in route_vty_out /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:9565 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x5570c08b5b65 in bgp_show_table /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11751 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#8 0x5570c08b677f in bgp_show_table_rd /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11915 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#9 0x5570c08b6d1c in bgp_show /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:11964 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#10 0x5570c08bcb03 in show_ip_bgp_magic /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_route.c:13134 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#11 0x5570c086f616 in show_ip_bgp bgpd/bgp_route_clippy.c:514 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#12 0x7efd469b38b6 (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b38b6) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#13 0x7efd469b3c43 in cmd_execute_command (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b3c43) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#14 0x7efd469b4915 in cmd_execute (/lib/x86_64-linux-gnu/libfrr.so.0+0x1b4915) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#15 0x7efd46b8581a (/lib/x86_64-linux-gnu/libfrr.so.0+0x38581a) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#16 0x7efd46b8a6ff (/lib/x86_64-linux-gnu/libfrr.so.0+0x38a6ff) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#17 0x7efd46b90f90 (/lib/x86_64-linux-gnu/libfrr.so.0+0x390f90) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#18 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#19 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#20 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#21 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: previously allocated by thread T0 here: > May 15 16:08:14 vRR-DUT bgpd[1647]: #0 0x7efd470b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#1 0x7efd46a6f7de in qcalloc (/lib/x86_64-linux-gnu/libfrr.so.0+0x26f7de) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#2 0x7efd46b8c5ba in vty_new (/lib/x86_64-linux-gnu/libfrr.so.0+0x38c5ba) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#3 0x7efd46b8f0fe (/lib/x86_64-linux-gnu/libfrr.so.0+0x38f0fe) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#4 0x7efd46b75257 in event_call (/lib/x86_64-linux-gnu/libfrr.so.0+0x375257) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#5 0x7efd46a42ecf in frr_run (/lib/x86_64-linux-gnu/libfrr.so.0+0x242ecf) > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#6 0x5570c06bf804 in main /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:545 > May 15 16:08:14 vRR-DUT bgpd[1647]: FRRouting#7 0x7efd46429d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > May 15 16:08:14 vRR-DUT bgpd[1647]: SUMMARY: AddressSanitizer: heap-use-after-free (/lib/x86_64-linux-gnu/libfrr.so.0+0x383f9f) in vty_out > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow bytes around the buggy address: > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a49f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > May 15 16:08:14 vRR-DUT bgpd[1647]: =>0x0c56803a4a40: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: 0x0c56803a4a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow byte legend (one shadow byte represents 8 application bytes): > May 15 16:08:14 vRR-DUT bgpd[1647]: Addressable: 00 > May 15 16:08:14 vRR-DUT bgpd[1647]: Partially addressable: 01 02 03 04 05 06 07 > May 15 16:08:14 vRR-DUT bgpd[1647]: Heap left redzone: fa > May 15 16:08:14 vRR-DUT bgpd[1647]: Freed heap region: fd > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack left redzone: f1 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack mid redzone: f2 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack right redzone: f3 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack after return: f5 > May 15 16:08:14 vRR-DUT bgpd[1647]: Stack use after scope: f8 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global redzone: f9 > May 15 16:08:14 vRR-DUT bgpd[1647]: Global init order: f6 > May 15 16:08:14 vRR-DUT bgpd[1647]: Poisoned by user: f7 > May 15 16:08:14 vRR-DUT bgpd[1647]: Container overflow: fc > May 15 16:08:14 vRR-DUT bgpd[1647]: Array cookie: ac > May 15 16:08:14 vRR-DUT bgpd[1647]: Intra object redzone: bb > May 15 16:08:14 vRR-DUT bgpd[1647]: ASan internal: fe > May 15 16:08:14 vRR-DUT bgpd[1647]: Left alloca redzone: ca > May 15 16:08:14 vRR-DUT bgpd[1647]: Right alloca redzone: cb > May 15 16:08:14 vRR-DUT bgpd[1647]: Shadow gap: cc > May 15 16:08:14 vRR-DUT bgpd[1647]: ==1647==ABORTING The vty_out() function detects a BROKEN PIPE error during the call of vtysh_flush() call, and closes the vty pointer. Consequently, the next vty_out() calls may use an invalid vty pointer. The call to vtysh_flush() has been added in a previous commit: this call does a syncronous write for a large buffer, which triggers the error. Propose to delay the removal of the vty pointer at the next scheduling. Until that event, keep the vty structure at CLOSE state. The show function will eventually detect the invalid vty status, and will anticipate the end of the show command. Fixes: 9112fb3 ("lib: Memory spike reduction for sh cmds at scale") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
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>
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>
Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > FRRouting#1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > FRRouting#2 0x7fa32474d783 in route_node_get lib/table.c:283 > FRRouting#3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > FRRouting#1 0x7fa324668d8f in qfree lib/memory.c:130 > FRRouting#2 0x7fa32474c421 in route_table_free lib/table.c:126 > FRRouting#3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7fa324668c4d in qcalloc lib/memory.c:105 > FRRouting#2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > FRRouting#3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 Ticket :#4279110 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
zebra: fix table heap-after-free crash Fix a heap-after-free that causes zebra to crash even without address-sanitizer. To reproduce: > echo "100 my_table" | tee -a /etc/iproute2/rt_tables > ip route add blackhole default table 100 > ip route show table 100 > ip l add red type vrf table 100 > ip l del red > ip route del blackhole default table 100 Zebra manages routing tables for all existing Linux RT tables, regardless of whether they are assigned to a VRF interface. When a table is not assigned to any VRF, zebra arbitrarily assigns it to the default VRF, even though this is not strictly accurate (the code expects this behavior). When an RT table is created after a VRF, zebra correctly assigns the table to the VRF. However, if a VRF interface is assigned to an existing RT table, zebra does not update the table owner, which remains as the default VRF. As a result, existing routing entries remain under the default VRF, while new entries are correctly assigned to the VRF. The VRF mismatch is unexpected in the code and creates crashes and memory related issues. Furthermore, Linux does not automatically delete RT tables when they are unassigned from a VRF. It is incorrect to delete these tables from zebra. Instead, at VRF disabling, do not release the table but reassign it to the default VRF. At VRF enabling, change the table owner back to the appropriate VRF. ``` > ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88 > READ of size 1 at 0x606000154f54 thread T0 > #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28 > FRRouting#1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28 > FRRouting#2 0x7fa32474d783 in route_node_get lib/table.c:283 > FRRouting#3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231 > FRRouting#4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957 > FRRouting#5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988 > FRRouting#6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894 > FRRouting#7 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > FRRouting#11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649) > > 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78) > freed by thread T0 here: > #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123 > FRRouting#1 0x7fa324668d8f in qfree lib/memory.c:130 > FRRouting#2 0x7fa32474c421 in route_table_free lib/table.c:126 > FRRouting#3 0x7fa32474bf96 in route_table_finish lib/table.c:46 > FRRouting#4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191 > FRRouting#5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214 > FRRouting#6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219 > FRRouting#7 0x7fa32476fabf in vrf_disable lib/vrf.c:326 > FRRouting#8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231 > FRRouting#9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478 > FRRouting#10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949 > FRRouting#11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#13 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#15 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 > > previously allocated by thread T0 here: > #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7fa324668c4d in qcalloc lib/memory.c:105 > FRRouting#2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38 > FRRouting#3 0x7fa32474e73c in route_table_init lib/table.c:512 > FRRouting#4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137 > FRRouting#5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358 > FRRouting#6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140 > FRRouting#7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286 > FRRouting#8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533 > FRRouting#9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968 > FRRouting#10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268 > FRRouting#11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954 > FRRouting#12 0x7fa32476689c in event_call lib/event.c:1996 > FRRouting#13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55b0e4e6c32a in main zebra/main.c:526 > FRRouting#15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308 ``` Ticket :#4279110 Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> # See merge request nbu-sws/CL/FRR/frr!1121
…show-rib-count increase show rib count FRR 8.2.2
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Signed-off-by: Daniel Walton dwalton@cumulusnetworks.com