- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 13 Nov '17

13 Nov '17

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. 2 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 2 of 2 defect(s) ** CID 1461328: Security best practices violations (TOCTOU) /lib/command.c: 1668 in file_write_config() ________________________________________________________________________________________________________ *** CID 1461328: Security best practices violations (TOCTOU) /lib/command.c: 1668 in file_write_config() 1662 if (errno != ENOENT) { 1663 vty_out(vty, 1664 "Can't unlink backup configuration file %s.\n", 1665 config_file_sav); 1666 goto finished; 1667 } >>> CID 1461328: Security best practices violations (TOCTOU) >>> Calling function "link" that uses "config_file" after a check function. This can cause a time-of-check, time-of-use race condition. 1668 if (link(config_file, config_file_sav) != 0) { 1669 vty_out(vty, 1670 "Can't backup old configuration file %s.\n", 1671 config_file_sav); 1672 goto finished; 1673 } ** CID 1461327: Security best practices violations (SECURE_TEMP) /lib/command.c: 1636 in file_write_config() ________________________________________________________________________________________________________ *** CID 1461327: Security best practices violations (SECURE_TEMP) /lib/command.c: 1636 in file_write_config() 1630 1631 1632 config_file_tmp = XMALLOC(MTYPE_TMP, strlen(config_file) + 8); 1633 sprintf(config_file_tmp, "%s.XXXXXX", config_file); 1634 1635 /* Open file to configuration write. */ >>> CID 1461327: Security best practices violations (SECURE_TEMP) >>> Calling "mkstemp" without securely setting umask first. 1636 fd = mkstemp(config_file_tmp); 1637 if (fd < 0) { 1638 vty_out(vty, "Can't open configuration file %s.\n", 1639 config_file_tmp); 1640 goto finished; 1641 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Results of FRR TSC 2017-10 Voting...
by Alistair Woodman 10 Nov '17

10 Nov '17

All, Here are the results of the FRR TSC vote. (sorry for the delay, I have been in transit) Eligible to vote: 18 Actually voted: 16 Turnout: 89% The following nominees were elected to the TSC: . Philippe Guibert . Donald Sharp . Renato Westphal . Russ White . Martin Winter . Quentin Young The following nominees were not: . Lou Berger . David Lamparter I'd like to thank everyone for participating in the process, and look forward to a repeat in 2018-10. /a

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 09 Nov '17

09 Nov '17

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 1461297: Null pointer dereferences (REVERSE_INULL) /bgpd/rfapi/bgp_rfapi_cfg.c: 1468 in vnc_export_nvegroup() ________________________________________________________________________________________________________ *** CID 1461297: Null pointer dereferences (REVERSE_INULL) /bgpd/rfapi/bgp_rfapi_cfg.c: 1468 in vnc_export_nvegroup() 1462 if (rfg_new == NULL) { 1463 rfg_new = bgp_rfapi_cfg_match_byname(bgp, argv[5]->arg, 1464 RFAPI_GROUP_CFG_VRF); 1465 vnc_add_vrf_opener(bgp, rfg_new); 1466 } 1467 >>> CID 1461297: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "rfg_new" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1468 if (rfg_new == NULL) { 1469 vty_out(vty, "Can't find group named \"%s\".\n", argv[5]->arg); 1470 return CMD_WARNING_CONFIG_FAILED; 1471 } 1472 1473 if (argv[2]->arg[0] == 'b') { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Slack access
by Juergen Werner 08 Nov '17

08 Nov '17

Hi, my name is Juergen and I recently raised my first pull request. An acquaintance of mine, @cfra, pointed me to this project and I would like to contribute to it. Is this the right place to ask for access to the Slack channel? Best regards, Juergen

3 2

Last Notice: TSC Voting ends in a few hours....
by Alistair Woodman 07 Nov '17

07 Nov '17

Dear FRR maintainers, Voting for the TSC will close before tomorrow's call. If you have not voted, but intend to, you only have a few hours.

1 0

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

06 Nov '17

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 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_vty.c: 4162 in show_ip_ospf_neighbor_sub() ________________________________________________________________________________________________________ *** CID 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_vty.c: 4162 in show_ip_ospf_neighbor_sub() 4156 4157 if (nbr->state == NSM_Attempt && 4158 nbr->router_id.s_addr == 0) 4159 strncpy(neigh_str, "neighbor", 4160 INET_ADDRSTRLEN); 4161 else >>> CID 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "neigh_str" of size 16 bytes might leave the destination string unterminated. 4162 strncpy(neigh_str, 4163 inet_ntoa(nbr->router_id), 4164 INET_ADDRSTRLEN); 4165 4166 json_object_object_get_ex(json, neigh_str, 4167 &json_neigh_array); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click 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 03 Nov '17

03 Nov '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1460438: Uninitialized variables (UNINIT) /eigrpd/eigrp_reply.c: 173 in eigrp_reply_receive() ________________________________________________________________________________________________________ *** CID 1460438: Uninitialized variables (UNINIT) /eigrpd/eigrp_reply.c: 173 in eigrp_reply_receive() 167 eigrp->topology_table, &dest_addr); 168 /* 169 * Destination must exists 170 */ 171 if (!dest) { 172 char buf[PREFIX_STRLEN]; >>> CID 1460438: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "buf" when calling "strlen". 173 zlog_err("%s: Received prefix %s which we do not know about", 174 __PRETTY_FUNCTION__, 175 prefix2str(&dest_addr, buf, strlen(buf))); 176 continue; 177 } 178 ** CID 1460437: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_reply.c: 160 in eigrp_reply_receive() ________________________________________________________________________________________________________ *** CID 1460437: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_reply.c: 160 in eigrp_reply_receive() 154 continue; 155 156 struct prefix dest_addr; 157 158 stream_set_getp(s, s->getp - sizeof(u_int16_t)); 159 >>> CID 1460437: Resource leaks (RESOURCE_LEAK) >>> Overwriting "tlv" in "tlv = eigrp_read_ipv4_tlv(s)" leaks the storage that "tlv" points to. 160 tlv = eigrp_read_ipv4_tlv(s); 161 162 dest_addr.family = AF_INET; 163 dest_addr.u.prefix4 = tlv->destination; 164 dest_addr.prefixlen = tlv->prefix_length; 165 struct eigrp_prefix_entry *dest = ** CID 1460436: Control flow issues (DEADCODE) /eigrpd/eigrp_query.c: 240 in eigrp_send_query() ________________________________________________________________________________________________________ *** CID 1460436: Control flow issues (DEADCODE) /eigrpd/eigrp_query.c: 240 in eigrp_send_query() 234 new_packet = true; 235 } 236 } 237 238 if (!has_tlv) { 239 if (ep) >>> CID 1460436: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "eigrp_packet_free(ep);". 240 eigrp_packet_free(ep); 241 return; 242 } 243 244 if ((ei->params.auth_type == EIGRP_AUTH_TYPE_MD5) 245 && ei->params.auth_keychain != NULL) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

A question about the # of vrf per router or switch can support by FRR?
by Jay Chen 03 Nov '17

03 Nov '17

Is there a limit that the # of vrf can support for a single switch or router by using FRR? Thanks, Jay

5 9

[Action] Nominations for the TSC...
by Alistair Woodman 27 Oct '17

27 Oct '17

Dear Maintainers, I'm looking for nominations for the TSC election. (Per the by-laws this election is due this month). I intend to follow the following process. 1) ask you (the maintainers) for new nominations to the TSC. (These can include self nominations) 2) assume existing TSC members will wish to continue (i.e. They are automatically nominated) (Any exiting TSC member wishing to stand down may unicast me) 3) create the union of the two sets 4) run the election per the "Multi-winner Single Transferable Vote" process per the TSC doc. Please provide me with nominations by COB this Friday the 27th. /a Sent from my iPad

2 2

FRR Zebra/FPM interactions
by Donald Sharp 25 Oct '17

25 Oct '17

Thorvald - Hi! I'm Donald Sharp, I'm working on FRR, I'm discussing with you this PR: https://github.com/FRRouting/frr/pull/1350 First I'd like to apologize for the slow response to your enquiries on the PR. I decided to reach out directly to you because I feel like email might be a bit better medium to talk about what our plans are and to describe what I see the future of zebra is. Our plans are not currently set in stone but we do have some broad strokes of what we want to accomplish: 1) Separate the south bound API in such a manner that we use a starting function call. Currently both the FPM interactions and zebra/rt.h are our south bound interfaces As an example rib_install_kernel does this: rib_install_kernel hook_call (rib_update) -> FPM interactions kernel_route_rib -> Rib install for kernel we are working on. if (success) Set some values We want it to do this: rib_install_kernel kernel_route_rib -> List of hooks to call: FPM Interactions Rib install for kernel we are working on Anything else we add as a rib_update hook if (success) Call kernel_route_rib_success() function Now rinse/repeat this for all rt.h southbound api's. 2) Separate processing of southbound api into it's own true pthread( not lib/thread.h ): Currently the FPM has a TAILQ_ENTRY(rib_dest_t_) in rib_dest_t(rib.h) to track and process FPM install/deletes/whatever.. I would like to convert this data structure to the control point for what has been communicated south bound. Then allow the southbound api's to bundle the installation into whatever however they would like to do so in a timeframe that it would like to do so as well. I think this would allow us to do things like bundling of netlink messages to the kernel. Kernel insertion on linux as it stands is absurdly slow and needs to be sped up. 3) Arbitrary hook levels: We would also like the ability for FPM interactions and Rib install hooks have the ability to have sub hooks as well if they would like to as well. As an example the rib interactions could have a route-map application hook before passing to the kernel. 4) Allow which hooks to be used via a control mechanism( this is what you were really asking for ) to control who get's called. As you noticed it would be nice to have a way to control which soutbound hooks are actually installed and used. Now where to start? I personally think we need to start with #1. #2 and #4 will flow from that imo. donald PS - If you would like more immediate access than email, we use a public slack (frrouting.slack.com) if you would like an invite please let me know.

1 0