- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 12 Apr '18

12 Apr '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 12 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 12 of 12 defect(s) ** CID 1467832: Null pointer dereferences (NULL_RETURNS) /pbrd/pbr_nht.c: 217 in pbr_nhgroup_add_cb() ________________________________________________________________________________________________________ *** CID 1467832: Null pointer dereferences (NULL_RETURNS) /pbrd/pbr_nht.c: 217 in pbr_nhgroup_add_cb() 211 nhgc = nhgc_find(name); 212 pnhgc = pbr_nht_add_group(name); 213 214 DEBUGD(&pbr_dbg_nht, "%s: Added nexthop-group %s", __PRETTY_FUNCTION__, 215 name); 216 >>> CID 1467832: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "nhgc". 217 pbr_nht_install_nexthop_group(pnhgc, nhgc->nhg); 218 pbr_map_check_nh_group_change(name); 219 } 220 221 void pbr_nhgroup_add_nexthop_cb(const struct nexthop_group_cmd *nhgc, 222 const struct nexthop *nhop) ** CID 1467831: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1467831: Null pointer dereferences (FORWARD_NULL) /pbrd/pbr_vty_clippy.c: 148 in pbr_map_nexthop_group() 142 } 143 #if 0 /* anything that can fail? */ 144 if (_failcnt) 145 return CMD_WARNING; 146 #endif 147 #endif >>> CID 1467831: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "name" to "pbr_map_nexthop_group_magic", which dereferences it. 148 return pbr_map_nexthop_group_magic(self, vty, argc, argv, no, name); 149 } 150 151 /* pbr_map_nexthop => "[no] set nexthop <A.B.C.D|X:X::X:X>$addr [INTERFACE]$intf [nexthop-vrf NAME$name]" */ 152 DEFUN_CMD_FUNC_DECL(pbr_map_nexthop) 153 #define funcdecl_pbr_map_nexthop static int pbr_map_nexthop_magic(\ ** CID 1467830: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1467830: Null pointer dereferences (FORWARD_NULL) /pbrd/pbr_vty_clippy.c: 265 in pbr_policy() 259 } 260 #if 0 /* anything that can fail? */ 261 if (_failcnt) 262 return CMD_WARNING; 263 #endif 264 #endif >>> CID 1467830: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "mapname" to "pbr_policy_magic", which dereferences it. 265 return pbr_policy_magic(self, vty, argc, argv, no, mapname); 266 } 267 268 /* show_pbr => "show pbr [json$json]" */ 269 DEFUN_CMD_FUNC_DECL(show_pbr) 270 #define funcdecl_show_pbr static int show_pbr_magic(\ ** CID 1467829: Resource leaks (RESOURCE_LEAK) /pbrd/pbr_vty.c: 348 in pbr_policy_magic() ________________________________________________________________________________________________________ *** CID 1467829: Resource leaks (RESOURCE_LEAK) /pbrd/pbr_vty.c: 348 in pbr_policy_magic() 342 if (pbrm) 343 pbr_map_add_interface(pbrm, ifp); 344 } 345 } 346 } 347 >>> CID 1467829: Resource leaks (RESOURCE_LEAK) >>> Variable "pbr_ifp" going out of scope leaks the storage it points to. 348 return CMD_SUCCESS; 349 } 350 351 DEFPY (show_pbr, 352 show_pbr_cmd, 353 "show pbr [json$json]", ** CID 1467828: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 779 in pbr_nht_get_installed() ________________________________________________________________________________________________________ *** CID 1467828: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 779 in pbr_nht_get_installed() 773 bool pbr_nht_get_installed(const char *name) 774 { 775 struct pbr_nexthop_group_cache find; 776 struct pbr_nexthop_group_cache *pnhgc; 777 778 memset(&find, 0, sizeof(find)); >>> CID 1467828: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "find.name" by copying "name" without checking the length. 779 strcpy(find.name, name); 780 781 pnhgc = hash_lookup(pbr_nhg_hash, &find); 782 783 if (!pnhgc) 784 return false; ** CID 1467827: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 436 in pbr_nht_change_group() ________________________________________________________________________________________________________ *** CID 1467827: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 436 in pbr_nht_change_group() 430 431 nhgc = nhgc_find(name); 432 if (!nhgc) 433 return; 434 435 memset(&find, 0, sizeof(find)); >>> CID 1467827: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "find.name" by copying "name" without checking the length. 436 strcpy(find.name, name); 437 pnhgc = hash_lookup(pbr_nhg_hash, &find); 438 439 if (!pnhgc) { 440 DEBUGD(&pbr_dbg_nht, 441 "%s: Could not find nexthop-group cache w/ name '%s'", ** CID 1467826: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 511 in pbr_nht_delete_individual_nexthop() ________________________________________________________________________________________________________ *** CID 1467826: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 511 in pbr_nht_delete_individual_nexthop() 505 pbrm->valid = false; 506 pbrms->nhs_installed = false; 507 pbrms->installed = false; 508 pbrms->reason |= PBR_MAP_INVALID_NO_NEXTHOPS; 509 510 memset(&find, 0, sizeof(find)); >>> CID 1467826: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "&find.name[0]" by copying "pbrms->internal_nhg_name" without checking the length. 511 strcpy(&find.name[0], pbrms->internal_nhg_name); 512 pnhgc = hash_lookup(pbr_nhg_hash, &find); 513 514 nh = pbrms->nhg->nexthop; 515 nh_afi = nh->type; 516 lup.nexthop = nh; ** CID 1467825: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 760 in pbr_nht_get_table() ________________________________________________________________________________________________________ *** CID 1467825: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 760 in pbr_nht_get_table() 754 uint32_t pbr_nht_get_table(const char *name) 755 { 756 struct pbr_nexthop_group_cache find; 757 struct pbr_nexthop_group_cache *pnhgc; 758 759 memset(&find, 0, sizeof(find)); >>> CID 1467825: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "find.name" by copying "name" without checking the length. 760 strcpy(find.name, name); 761 pnhgc = hash_lookup(pbr_nhg_hash, &find); 762 763 if (!pnhgc) { 764 DEBUGD(&pbr_dbg_nht, 765 "%s: Could not find nexthop-group cache w/ name '%s'", ** CID 1467824: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 605 in pbr_nht_nexthop_group_valid() ________________________________________________________________________________________________________ *** CID 1467824: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 605 in pbr_nht_nexthop_group_valid() 599 { 600 struct pbr_nexthop_group_cache *pnhgc; 601 struct pbr_nexthop_group_cache lookup; 602 603 DEBUGD(&pbr_dbg_nht, "%s: %s", __PRETTY_FUNCTION__, name); 604 >>> CID 1467824: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "lookup.name" by copying "name" without checking the length. 605 strcpy(lookup.name, name); 606 pnhgc = hash_get(pbr_nhg_hash, &lookup, NULL); 607 if (!pnhgc) 608 return false; 609 DEBUGD(&pbr_dbg_nht, "%s: \t%d %d", __PRETTY_FUNCTION__, pnhgc->valid, 610 pnhgc->installed); ** CID 1467823: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 546 in pbr_nht_add_group() ________________________________________________________________________________________________________ *** CID 1467823: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_nht.c: 546 in pbr_nht_add_group() 540 if (!nhgc) { 541 zlog_warn("%s: Could not find group %s to add", 542 __PRETTY_FUNCTION__, name); 543 return NULL; 544 } 545 >>> CID 1467823: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "lookup.name" by copying "name" without checking the length. 546 strcpy(lookup.name, name); 547 pnhgc = hash_get(pbr_nhg_hash, &lookup, pbr_nhgc_alloc); 548 DEBUGD(&pbr_dbg_nht, "%s: Retrieved NHGC @ %p", __PRETTY_FUNCTION__, 549 pnhgc); 550 551 for (ALL_NEXTHOPS(nhgc->nhg, nhop)) { ** CID 1467822: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_map.c: 271 in pbrms_get() ________________________________________________________________________________________________________ *** CID 1467822: Security best practices violations (STRING_OVERFLOW) /pbrd/pbr_map.c: 271 in pbrms_get() 265 struct pbr_map_sequence *pbrms; 266 struct listnode *node; 267 268 pbrm = pbrm_find(name); 269 if (!pbrm) { 270 pbrm = XCALLOC(MTYPE_PBR_MAP, sizeof(*pbrm)); >>> CID 1467822: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "pbrm->name" by copying "name" without checking the length. 271 strcpy(pbrm->name, name); 272 273 pbrm->seqnumbers = list_new(); 274 pbrm->seqnumbers->cmp = 275 (int (*)(void *, void *))pbr_map_sequence_compare; 276 pbrm->seqnumbers->del = ** CID 1467821: (STRING_OVERFLOW) /pbrd/pbr_vty.c: 332 in pbr_policy_magic() /pbrd/pbr_vty.c: 341 in pbr_policy_magic() ________________________________________________________________________________________________________ *** CID 1467821: (STRING_OVERFLOW) /pbrd/pbr_vty.c: 332 in pbr_policy_magic() 326 327 if (pbrm) 328 pbr_map_interface_delete(pbrm, ifp); 329 } 330 } else { 331 if (strcmp(pbr_ifp->mapname, "") == 0) { >>> CID 1467821: (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "pbr_ifp->mapname" by copying "mapname" without checking the length. 332 strcpy(pbr_ifp->mapname, mapname); 333 334 if (pbrm) 335 pbr_map_add_interface(pbrm, ifp); 336 } else { 337 if (!(strcmp(pbr_ifp->mapname, mapname) == 0)) { /pbrd/pbr_vty.c: 341 in pbr_policy_magic() 335 pbr_map_add_interface(pbrm, ifp); 336 } else { 337 if (!(strcmp(pbr_ifp->mapname, mapname) == 0)) { 338 old_pbrm = pbrm_find(pbr_ifp->mapname); 339 if (old_pbrm) 340 pbr_map_interface_delete(old_pbrm, ifp); >>> CID 1467821: (STRING_OVERFLOW) >>> You might overrun the 100-character fixed-size string "pbr_ifp->mapname" by copying "mapname" without checking the length. 341 strcpy(pbr_ifp->mapname, mapname); 342 if (pbrm) 343 pbr_map_add_interface(pbrm, ifp); 344 } 345 } 346 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

4/10 Technical Meeting Notes
by Quentin Young 11 Apr '18

11 Apr '18

Issues ====== - #2018: Vincent, Philippe: we would like to be able to call iptables & other external programs from zebra Donald, Lou: Security concerns here, would be better to use a module Lou: Perhaps use FPM to interface with Zebra without integrating this code directly into Zebra Vincent, Philippe: We'll take a look - #2030: Donald: Requested that start/stop of FRR on Alpine be similar to other platforms, submitter agreed, work in progress - #2040: Unsure if bug, probable workaround commented in issue Pull Requests ============= - #1853: Donald to continue looking at this PR, still some config-related CI issues to clear up - #1881: Olivier: not quite correct yet, will update to use label manager & change CLI - #1883: Quentin & Donald: It does not make sense to add a checkpatch patch that will run for a single PR and never again Lou: Can't guarantee that it will never run again, and important to have clear policy Paul: How about we document agreed-upon exceptions as a compromise? All: sounds good - #1905: Donald to look again - #1916: Waiting on Mitesh to do what needs to be done - #1950: Donald to review again - #1976: Donald: NetNS is a poor abstraction that requires this patch... Vincent: This is how it's done on non-VRF supporting platforms [provides some references] Donald: Will read references, review again and continue conversation - #2009: Merged - #2025: See discussion for #2018 - #2033: Donald + Lou to review - #2035: In discussions - #2036: Philippe has review comments, Donald to look at changes addressing previous comments - #2038: Merged - #2039: Broken packaging for now - #2043: Debug cleanups & route replace semantic improvements for Zebra Renato to review

3 2

Announcing PBR for FRR
by Donald Sharp 11 Apr '18

11 Apr '18

All - I'd like to announce the availability of a new daemon for FRR on the master branch. PBR( Policy Based Routing ) allows operators to setup policy maps that allow special control forwarding. To configure PBR, see `doc/user/pbr.rst`. Here is a quick example of how to configure: nexthop-group EVA nexthop 4.3.2.1 swp5 nexthop 6.4.3.2 ! pbr-map DONNA seq 10 match src-ip 192.168.210.0/24 match dst-ip 192.168.140.0/24 set nexthop-group EVA ! int swp54 pbr-policy DONNA ! This configuration says, on the incoming interface swp54 if the src matches 192.168.210.0/24 and the dest matches 192.168.140.0/24, use nexthop-group EVA for forwarding the packet. I'd like to thank Vivek, Don, Quentin, Philippe and Russ for their hard work on getting this code into FRR. thanks! donald

1 0

FRRouting - RIP VRF Support.
by amit.tiwari＠inventum.net 09 Apr '18

09 Apr '18

Hi Kunihiro, I have compiled FRRouting master branch and deployed it on my router, bgp and ospf are working fine with vrf. Whereas, in case of RIP, vrf doesn't seems to be working, there is no vrf support even at CLI level. May we know, when are you guys releasing frrouting with full vrf support in RIP. Regards, Amit Kumar Tiwari 9953769181

3 2

please invite me to slack channel.
by abbas ali chezgi 09 Apr '18

09 Apr '18

please invite me to slack channel. -- ================================= chezgi,abbas ali MSC student at computer Architecture Department of Electronic and Computer Engineering Isfahan University of Technology Isfahan Iran email: chezgi(AT)ec(DOT)iut(DOT)ac(DOT)ir =================================

2 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 06 Apr '18

06 Apr '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1467487: (RESOURCE_LEAK) /ospf6d/ospf6_intra.c: 1720 in ospf6_intra_prefix_lsa_remove() /ospf6d/ospf6_intra.c: 1914 in ospf6_intra_prefix_lsa_remove() ________________________________________________________________________________________________________ *** CID 1467487: (RESOURCE_LEAK) /ospf6d/ospf6_intra.c: 1720 in ospf6_intra_prefix_lsa_remove() 1714 if (prefix_num == 0) 1715 break; 1716 if (end < current + OSPF6_PREFIX_SIZE(op)) 1717 break; 1718 prefix_num--; 1719 >>> CID 1467487: (RESOURCE_LEAK) >>> Overwriting "route_to_del" in "route_to_del = ospf6_route_create()" leaks the storage that "route_to_del" points to. 1720 route_to_del = ospf6_route_create(); 1721 1722 memset(&route_to_del->prefix, 0, sizeof(struct prefix)); 1723 route_to_del->prefix.family = AF_INET6; 1724 route_to_del->prefix.prefixlen = op->prefix_length; 1725 ospf6_prefix_in6_addr(&route_to_del->prefix.u.prefix6, op); /ospf6d/ospf6_intra.c: 1914 in ospf6_intra_prefix_lsa_remove() 1908 1909 ospf6_route_delete(route_to_del); 1910 } 1911 1912 if (current != end && IS_OSPF6_DEBUG_EXAMIN(INTRA_PREFIX)) 1913 zlog_debug("Trailing garbage ignored"); >>> CID 1467487: (RESOURCE_LEAK) >>> Variable "route_to_del" going out of scope leaks the storage it points to. 1914 } 1915 1916 void ospf6_intra_route_calculation(struct ospf6_area *oa) 1917 { 1918 struct ospf6_route *route, *nroute; 1919 uint16_t type; ** CID 1467486: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_mplsvpn.c: 475 in leak_update() ________________________________________________________________________________________________________ *** CID 1467486: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_mplsvpn.c: 475 in leak_update() 469 /* 470 * nexthop tracking for unicast routes 471 */ 472 struct bgp *bgp_nexthop = bgp; 473 int nh_valid; 474 >>> CID 1467486: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "new->extra" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 475 if (new->extra && new->extra->bgp_orig) 476 bgp_nexthop = new->extra->bgp_orig; 477 478 /* 479 * No nexthop tracking for redistributed routes because 480 * their originating protocols will do the tracking and ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 04 Apr '18

04 Apr '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1467453: Resource leaks (RESOURCE_LEAK) /vtysh/vtysh.c: 318 in vtysh_execute_func() ________________________________________________________________________________________________________ *** CID 1467453: Resource leaks (RESOURCE_LEAK) /vtysh/vtysh.c: 318 in vtysh_execute_func() 312 if (vline == NULL) 313 return CMD_SUCCESS; 314 315 if (user_mode) { 316 if (strncmp("en", vector_slot(vline, 0), 2) == 0) { 317 fprintf(stdout, "%% Command not allowed: enable\n"); >>> CID 1467453: Resource leaks (RESOURCE_LEAK) >>> Variable "vline" going out of scope leaks the storage it points to. 318 return CMD_WARNING; 319 } 320 } 321 322 saved_ret = ret = cmd_execute_command(vline, vty, &cmd, 1); 323 saved_node = vty->node; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

why fork Quagga?
by Carla Schroder 03 Apr '18

03 Apr '18

Hello FRR devs, I'm writing an article on FRRouting for Linux.com. I've read a number of articles on why it was forked from Quagga (for example http://www.enterprisenetworkingplanet.com/netsp/free-range-routing-protocol… and http://packetpushers.net/free-range-routing-project-forks-quagga/) Is there anything anyone would like to add or correct? It's not a huge deal and I'm not looking for scandals. Readers will want to know the reasons for forking. It looks like the tl;dr version is 'quagga was bottlenecked by a single maintainer and development stalled'. I've also seen discussion on frrouting.org about new features and support for additional protocols-- anyone care to comment what these new things mean for network admins? You don't have to write a book, summaries like "We're working on support for Foov5, which means transferring good beer securely over untrusted networks!" are good. If there is anything else you think is cool and needs to be shared, throw that in too. I will attribute any comments that I use, so if you want to be anonymous let me know. My deadline is Tuesday evening. I know that's not much time--welcome to my world :) thanks, Carla -- ++++++++++++++++++++++++++++++++++++++++ Ace Linux guru + carlaschroder.com + Where words fail, music speaks. + ++++++++++++++++++++++++++++++++++++++++

8 10

Re: [dev] why fork Quagga?
by Russ White 03 Apr '18

03 Apr '18

Carla -- I saw your message on the FR dev list -- if there is anything I can help you with, in terms of getting the right information down, or reviewing, let me know. 😊 Russ

1 0

`default` keyword?
by Donald Sharp 30 Mar '18

30 Mar '18

So currently if you want to specify the default vrf as a string you have to use: Default-IP-Routing-Table Do people have opinions on what to use? I am thinking of making the keyword `default` special in that it will allow lookup of the default vrf if entered. thoughts? doanld

9 9