A small collection of patches that fix issues found by valgrind #1

donaldsharp · 2016-12-16T02:32:30Z

This cleanup clears a bgp crash on shutdown and some other minor valgrind issues.

There exists a possibility that when we cleanup for shutdown that we may attempt to access them again. Found via valgrind, stopped showing up in there. Signed-off-by: Donald Sharp <[email protected]>

Valgrind found this issue. This cleans it up from happening. Signed-off-by: Donald Sharp <[email protected]>

The first time through calling 'show ip bgp summary' we were always calculating the variable hostname field size incorrectly. Signed-off-by: Donald Sharp <[email protected]>

…rminated (BUFFER_SIZE_WARNING) Coverity: buffer_size_warning: Calling strncpy with a maximum size argument of 100 bytes on destination array pid_file of size 100 bytes might leave the destination string unterminated. Signed-off-by: Martin Winter <[email protected]>

… too small (BUFFER_SIZE) Coverity: buffer_size: You might overrun the 108 byte destination string addr.sun_path by writing the maximum 4095 bytes from path. Signed-off-by: Martin Winter <[email protected]>

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <[email protected]>

…ERFLOW) Coverity: string_overflow: You might overrun the 100-character destination string vty_path by writing 4096 characters from vty_sock_path. Signed-off-by: Martin Winter <[email protected]>

…eset * rip_interface.c: Default for split_horizon_default differed between rip_interface_new and rip_interface_reset, causing at least some issues after interface events. See patchwork FRRouting#604. Fix, and consolidate code. (rip_interface_{reset,clean}) rename these to 'interface', as that's more appropriate. Spin the ri specific bodies of these functions out to rip_interface_{reset,clean} helpers. Factor out the overlaps, so rip_interface_reset uses rip_interface_clean. (rip_interface_new) just use rip_interface_reset. * ripd.h: Update for (rip_interface_{reset,clean}) Reported by xufeng zhang, with a suggested fix on which this commit expands. See patchwork FRRouting#604. This commit addresses only the split-horizon discrepency, issue #2. The other issue they reported, #1, is not addressed, though suggested fix seems inappropriate. Cc: [email protected]

…7-whitespace2 to master-frr-upstream-sync-2017-07 * commit '87122d314c90f2e023b5fcebe514a1ddc2a59eb9': (21 commits) Remove FRR-hacking.md documentation Add OSPF API and FRR Hacking documents ospf6d: crash in ospf6_lsdb_show bgpd: fix peer startup for labeled-unicast if linklocal address not found replace space to tabs, add kernel styles multiline, remove trailing whitespaces. Add note about bridge limitations whitespace internal 2 internal reindent lib: route_node_lookup() needs to apply_mask() to prefix Add 1 more identation to correspond to kernel style multi-line comment ospf6d: crash in ospf6_lsdb_show bgpd: fix peer startup for labeled-unicast if linklocal address not found replace space to tabs, add kernel styles multiline, remove trailing whitespaces. *: reindent pt. 2 Add note about bridge limitations eigrpd: remove last vty_outln *: reindent *: add indent control files Remove FRR-hacking.md documentation Add OSPF API and FRR Hacking documents ...

Signed-off-by: Daniel Walton <[email protected]> Before ====== cel-redxp-10# show ip bgp 20.1.3.0/24 BGP routing table entry for 20.1.3.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: top1(10.1.1.2) bottom0(20.1.2.2) 4294967292 20.1.2.2 from bottom0(20.1.2.2) (20.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, bestpath-from-AS -4, best Community: 99:1 AddPath ID: RX 0, TX 92 Last update: Wed Sep 27 16:02:34 2017 cel-redxp-10# After ===== cel-redxp-10# show ip bgp 20.1.3.0/24 BGP routing table entry for 20.1.3.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: bottom0(20.1.2.2) 4294967292 20.1.2.2 from bottom0(20.1.2.2) (20.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, bestpath-from-AS 4294967292, best Community: 99:1 AddPath ID: RX 0, TX 2 Last update: Wed Sep 27 16:07:09 2017 cel-redxp-10#

The transposed SID value is not visible from the VPN paths. > r1# show bgp ipv4 vpn 10.0.0.0/24 > BGP routing table entry for 65001:20:10.0.0.0/24, version 3 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > 2001:db8:12::2 > Local > 0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf Vrf20(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:0:20 > Originator: 192.0.2.1 > Remote label: 16 > Remote SID: 2004:db8:1:1::, sid structure=[40 24 16 0 16 64] > Last update: Wed Nov 26 10:36:13 2025 Add a json field named remoteTransposedSid in json part. > r1# show bgp ipv4 vpn 10.0.0.0/24 json > "originatorId":"192.0.2.1", > "remoteLabel":16, > "remoteTransposedSid":"2004:db8:1:1:1::", > "remoteSid":"2004:db8:1:1::", > "remoteSidStructure":{ > "locatorBlockLen":40, > "locatorNodeLen":24, > "functionLen":16, > "argumentLen":0, > "transpositionLen":16, > "transpositionOffset":64 > }, Signed-off-by: Philippe Guibert <[email protected]>

When neighbor graceful-shutdown is configured, GSHUT community and LOCAL_PREF=0 should apply to all routes advertised to that neighbor, including locally originated routes (network command, redistribute). Previously, GSHUT only applied to received routes from that neighbor. This fix ensures originated routes also get GSHUT treatment. When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best FRRouting#1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <[email protected]>

The transposed SID value is not visible from the VPN paths. > r1# show bgp ipv4 vpn 10.0.0.0/24 > BGP routing table entry for 65001:20:10.0.0.0/24, version 3 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > 2001:db8:12::2 > Local > 0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf Vrf20(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:0:20 > Originator: 192.0.2.1 > Remote label: 16 > Remote SID: 2004:db8:1:1::, sid structure=[40 24 16 0 16 64] > Last update: Wed Nov 26 10:36:13 2025 Add a json field named remoteTransposedSid in json part. > r1# show bgp ipv4 vpn 10.0.0.0/24 json > "originatorId":"192.0.2.1", > "remoteLabel":16, > "remoteTransposedSid":"2004:db8:1:1:1::", > "remoteSid":"2004:db8:1:1::", > "remoteSidStructure":{ > "locatorBlockLen":40, > "locatorNodeLen":24, > "functionLen":16, > "argumentLen":0, > "transpositionLen":16, > "transpositionOffset":64 > }, Signed-off-by: Philippe Guibert <[email protected]>

Error: ERROR: AddressSanitizer: heap-use-after-free on address 0x6070000ef8a0 at pc 0x555df66ba094 bp 0x7ffc13d67240 sp 0x7ffc13d67238 READ of size 4 at 0x6070000ef8a0 thread T0 #0 0x555df66ba093 in zebra_gr_delete_stale_route_table_afi zebra/zebra_gr.c:514 FRRouting#1 0x7fd33d6db06e in event_call lib/event.c:2013 FRRouting#2 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257 FRRouting#3 0x555df66531ec in main zebra/main.c:552 FRRouting#4 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#5 0x7fd33d10c304 in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#6 0x555df6626b40 in _start (/usr/lib/frr/zebra+0x1a1b40) 0x6070000ef8a0 is located 0 bytes inside of 72-byte region [0x6070000ef8a0,0x6070000ef8e8) freed by thread T0 here: #0 0x7fd33dab76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52 FRRouting#1 0x7fd33d622cd5 in qfree lib/memory.c:136 FRRouting#2 0x555df66b9e5f in zebra_gr_client_info_delete zebra/zebra_gr.c:130 FRRouting#3 0x555df66bc66f in zread_client_capabilities zebra/zebra_gr.c:355 FRRouting#4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228 FRRouting#5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565 FRRouting#6 0x7fd33d6db06e in event_call lib/event.c:2013 FRRouting#7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257 FRRouting#8 0x555df66531ec in main zebra/main.c:552 FRRouting#9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: #0 0x7fd33dab83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 FRRouting#1 0x7fd33d6223e2 in qcalloc lib/memory.c:111 FRRouting#2 0x555df66bbace in zebra_gr_client_info_create zebra/zebra_gr.c:101 FRRouting#3 0x555df66bbace in zread_client_capabilities zebra/zebra_gr.c:360 FRRouting#4 0x555df66a025c in zserv_handle_commands zebra/zapi_msg.c:4228 FRRouting#5 0x555df67cde33 in zserv_process_messages zebra/zserv.c:565 FRRouting#6 0x7fd33d6db06e in event_call lib/event.c:2013 FRRouting#7 0x7fd33d5fffa1 in frr_run lib/libfrr.c:1257 FRRouting#8 0x555df66531ec in main zebra/main.c:552 FRRouting#9 0x7fd33d10c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Pooja Jagadeesh Doijode <[email protected]>

When using the 'sid vpn per-vrf export explicit' command, there is no control to know if the sid func part is corretly encoded in the BGP update. If the func part is over the 20 bit value, then there is missing information, and summing up the label and the sid info is not enough. For instance, the value cece:2222 has to be encoded in the 32 bit func part. > segment-routing > srv6 > locators > locator loc1 > prefix fc00:0:5::/48 block-len 32 node-len 16 func-bits 32 > ! > ! > ! > ! > router bgp 5 vrf vrf10 > address-family ipv6 unicast > sid vpn export explicit fc00:0:5:cece:2222:: > [..] But BGP does not know how to encode the whole SID information. > rt5# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > fc00:0:1::1 > Local > :: from :: (5.5.5.5) vrf vrf10(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:99:99 > Originator: 5.5.5.5 > Remote label: 0 > Remote SID: fc00:0:5:: > Last update: Mon Jun 30 17:15:50 2025 In the case, the function bit length of the locator is over 20 bits, consider encoding the SID in the prefix SID TLV, and do not use the label value. > rt1# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > fc00:0:5::1 fc00:0:6::1 > 5 > fc00:0:5::1 (metric 20) from fc00:0:5::1 (5.5.5.5) > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:99:99 > Remote label: 3 > Remote SID: fc00:0:5:cece:2222:: > Last update: Mon Jun 30 17:00:05 2025 Signed-off-by: Philippe Guibert <[email protected]>

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

When using the 'sid vpn per-vrf export explicit' command, there is no control to know if the sid func part is corretly encoded in the BGP update. If the func part is over the 20 bit value, then there is missing information, and summing up the label and the sid info is not enough. For instance, the value cece:2222 has to be encoded in the 32 bit func part. > segment-routing > srv6 > locators > locator loc1 > prefix fc00:0:5::/48 block-len 32 node-len 16 func-bits 32 > ! > ! > ! > ! > router bgp 5 vrf vrf10 > address-family ipv6 unicast > sid vpn export explicit fc00:0:5:cece:2222:: > [..] But BGP does not know how to encode the whole SID information. > rt5# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > fc00:0:1::1 > Local > :: from :: (5.5.5.5) vrf vrf10(7) announce-nh-self > Origin incomplete, metric 0, weight 32768, valid, sourced, local, best (First path received) > Extended Community: RT:99:99 > Originator: 5.5.5.5 > Remote label: 0 > Remote SID: fc00:0:5:: > Last update: Mon Jun 30 17:15:50 2025 In the case, the function bit length of the locator is over 20 bits, consider encoding the SID in the prefix SID TLV, and do not use the label value. > rt1# show bgp ipv6 vpn 2001:db9:10::/64 > BGP routing table entry for 5:10:2001:db9:10::/64, version 1 > not allocated > Paths: (1 available, best FRRouting#1) > Advertised to peers: > fc00:0:5::1 fc00:0:6::1 > 5 > fc00:0:5::1 (metric 20) from fc00:0:5::1 (5.5.5.5) > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:99:99 > Remote label: 3 > Remote SID: fc00:0:5:cece:2222:: > Last update: Mon Jun 30 17:00:05 2025 Signed-off-by: Philippe Guibert <[email protected]>

The following crash happens, when moving from level-2 to level-1 an isis flex-algorithm configuration > warning: 44 ./nptl/pthread_kill.c: No such file or directory > [Current thread is 1 (Thread 0x7108d4cb2980 (LWP 1023))] > (gdb) bt > #0 __pthread_kill_implementation (no_tid=0, signo=11, > threadid=<optimized out>) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=11, threadid=<optimized out>) > at ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=11) > at ./nptl/pthread_kill.c:89 > #3 0x00007108d3e4527e in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 > #4 0x00007108d4b44926 in core_handler (signo=11, siginfo=0x7ffe7c10fb30, > context=0x7ffe7c10fa00) > at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:248 > #5 <signal handler called> > #6 0x00005b5d803bf07b in isis_spf_invalidate_routes (tree=0x0) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2118 > #7 0x00005b5d803fb23e in isis_area_invalidate_routes (area=0x5b5db8d5be40, > levels=1) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isisd.c:3152 > #8 0x00005b5d803bf280 in isis_run_spf_cb (thread=0x7ffe7c110180) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_spf.c:2165 > #9 0x00007108d4b5ff7f in event_call (thread=0x7ffe7c110180) > at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:2011 > #10 0x00007108d4adb761 in frr_run (master=0x5b5db7f7ca40) > at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1219 > #11 0x00005b5d8038333a in main (argc=5, argv=0x7ffe7c1103d8, > --Type <RET> for more, q to quit, c to continue without paging-- > envp=0x7ffe7c110408) > at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:360 > (gdb) Fix this by adding protection before invalidating all routes. Signed-off-by: Philippe Guibert <[email protected]> (cherry picked from commit 65269be)

donaldsharp added 3 commits December 15, 2016 21:00

lib: Ensure ptrs are NULL on free

8eefe20

There exists a possibility that when we cleanup for shutdown that we may attempt to access them again. Found via valgrind, stopped showing up in there. Signed-off-by: Donald Sharp <[email protected]>

bgpd: Cleanup double read of free'd data

26acb92

Valgrind found this issue. This cleans it up from happening. Signed-off-by: Donald Sharp <[email protected]>

bgpd: Fix 'show ip bgp summary' variable output being wrong

c9d5bd2

The first time through calling 'show ip bgp summary' we were always calculating the variable hostname field size incorrectly. Signed-off-by: Donald Sharp <[email protected]>

donaldsharp requested a review from eqvinox December 16, 2016 02:32

qlyoung approved these changes Dec 16, 2016

View reviewed changes

eqvinox approved these changes Dec 16, 2016

View reviewed changes

eqvinox merged commit d5444d2 into FRRouting:stable/2.0 Dec 16, 2016

donaldsharp mentioned this pull request Dec 16, 2016

isis crash #4

Closed

donaldsharp pushed a commit that referenced this pull request Feb 14, 2017

zebra: Fix CID 1399335 (#1 of 1): Wrong sizeof argument (SIZEOF_MISMA…

4fdeb6b

…TCH) Needs to be size of correct structure (prefix instead of prefix_ipv4) Signed-off-by: Martin Winter <[email protected]>

donaldsharp deleted the stable_patches branch May 17, 2017 12:01

anithanarasimhamurthy mentioned this pull request May 17, 2017

nhrpd crash on unconfig of nhrp event socket #570

Closed

rwestphal mentioned this pull request Jun 7, 2017

Add Pseudowire management in Zebra #601

Closed

pguibert6WIND mentioned this pull request Jul 17, 2017

frr/master :crash vnc at startup #825

Closed

donaldsharp mentioned this pull request Sep 5, 2017

large-community regex crash #1103

Closed

louberger mentioned this pull request Sep 7, 2017

bgpd: route map changes not propagated to existing static network (ipv4 unicast tested) #1117

Closed

donaldsharp mentioned this pull request Sep 8, 2017

ospfv3 is failing in topotests #1135

Closed

dwalton76 mentioned this pull request Sep 27, 2017

bgpd: fix 4-byte AS display in bestpath-from-AS #1261

Merged

donaldsharp mentioned this pull request Oct 20, 2017

Allow VRFs for FPM #1343

Closed

louberger mentioned this pull request Dec 13, 2017

Sa from clang #1547

Merged

donaldsharp mentioned this pull request Jan 11, 2018

zebra route-leaking for static routes #1618

Merged

nevzorofff mentioned this pull request Jan 12, 2018

Downs't watch on MTU change #1601

Closed

louberger mentioned this pull request Jan 24, 2018

FRR pthread improvements #1672

Merged

skydevil56 mentioned this pull request Mar 31, 2018

NS initialisation failure (Permission denied) #2007

Closed

louberger mentioned this pull request Apr 3, 2018

lib: remove IRDP_NODE #2006

Merged

pguibert6WIND mentioned this pull request Dec 12, 2025

bgpd: add remoteTransposedSid value in json output of vpn paths #20255

Merged

foxnetwork-ru mentioned this pull request Jan 12, 2026

bgpd extcommunity dmzlink-bw is incompatible with Cisco #20444

Open

2 tasks

alessandro599 mentioned this pull request Jan 12, 2026

EVPN host (macip) /32 routes are not installed in FIB. #20376

Open

2 tasks

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20458

Merged

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20459

Merged

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20460

Merged

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20461

Merged

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20462

Merged

mergify bot mentioned this pull request Jan 13, 2026

isisd: fix crash when changing isis type (backport #20171) #20463

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

A small collection of patches that fix issues found by valgrind #1

A small collection of patches that fix issues found by valgrind #1

Uh oh!

donaldsharp commented Dec 16, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

A small collection of patches that fix issues found by valgrind #1

A small collection of patches that fix issues found by valgrind #1

Uh oh!

Conversation

donaldsharp commented Dec 16, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants