- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 11 Aug '20

11 Aug '20

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 1496642: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1496642: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_route.c: 3072 in bgp_filtered_routes_count() 3066 3067 for (dest = bgp_table_top(table); dest; dest = bgp_route_next(dest)) { 3068 for (ain = dest->adj_in; ain; ain = ain->next) { 3069 const struct prefix *rn_p = bgp_dest_get_prefix(dest); 3070 struct attr attr = {}; 3071 >>> CID 1496642: Null pointer dereferences (FORWARD_NULL) >>> Passing "&attr" to "bgp_input_filter", which dereferences null "attr.aspath". 3072 if (bgp_input_filter(peer, rn_p, &attr, afi, safi) 3073 == FILTER_DENY) 3074 count++; 3075 } 3076 } 3077 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

06 Aug '20

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 6 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 6 of 6 defect(s) ** CID 1496619: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1496619: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_evpn_mh.c: 360 in zebra_evpn_es_evi_show_vni() 354 vty_out(vty, "%-8s %-30s %-4s\n", "VNI", "ESI", "Type"); 355 } 356 } else { 357 if (!uj) 358 vty_out(vty, "VNI %d doesn't exist\n", vni); 359 } >>> CID 1496619: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "zvni" to "zebra_evpn_es_evi_show_one_vni", which dereferences it. 360 zebra_evpn_es_evi_show_one_vni(zvni, vty, json, detail); 361 } 362 363 /* Initialize the ES tables maintained per-L2_VNI */ 364 void zebra_evpn_vni_es_init(zebra_vni_t *zvni) 365 { ** CID 1496618: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1496618: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn_mh.c: 909 in bgp_evpn_type1_route_update() 903 attr_new = pi->attr; 904 905 /* Perform route selection; 906 * this is just to set the flags correctly as local route in 907 * the ES always wins. 908 */ >>> CID 1496618: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "vpn" to "evpn_route_select_install", which dereferences it. 909 evpn_route_select_install(bgp, vpn, rn); 910 bgp_dest_unlock_node(rn); 911 912 /* If this is a new route or some attribute has changed, export the 913 * route to the global table. The route will be advertised to peers 914 * from there. Note that this table is a 2-level tree (RD-level + ** CID 1496617: Memory - illegal accesses (USE_AFTER_FREE) ________________________________________________________________________________________________________ *** CID 1496617: Memory - illegal accesses (USE_AFTER_FREE) /zebra/zebra_evpn_mh.c: 1688 in zebra_evpn_es_cleanup() 1682 struct zebra_evpn_es *es; 1683 struct zebra_evpn_es *es_next; 1684 1685 RB_FOREACH_SAFE(es, zebra_es_rb_head, 1686 &zmh_info->es_rb_tree, es_next) { 1687 zebra_evpn_local_es_del(es); >>> CID 1496617: Memory - illegal accesses (USE_AFTER_FREE) >>> Calling "zebra_evpn_remote_es_flush" dereferences freed pointer "es". 1688 zebra_evpn_remote_es_flush(es); 1689 } 1690 } 1691 1692 /* Only certain types of access ports can be setup as an Ethernet Segment */ 1693 bool zebra_evpn_is_if_es_capable(struct zebra_if *zif) ** CID 1496616: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 6885 in zebra_vxlan_proc_sync_neigh_update() ________________________________________________________________________________________________________ *** CID 1496616: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 6885 in zebra_vxlan_proc_sync_neigh_update() 6879 if (old_bgp_ready) { 6880 zvni_neigh_send_del_to_client(zvni->vni, &n->ip, 6881 &n->emac, n->flags, n->state, 6882 false /*force*/); 6883 old_bgp_ready = false; 6884 } >>> CID 1496616: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "n->mac" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 6885 if (n->mac) 6886 zebra_vxlan_local_neigh_deref_mac(n, 6887 false /*send_mac_update*/); 6888 } 6889 /* clear old fwd info */ 6890 n->rem_seq = 0; ** CID 1496615: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /zebra/rt_netlink.c: 3206 in netlink_macfdb_update_ctx() ________________________________________________________________________________________________________ *** CID 1496615: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /zebra/rt_netlink.c: 3206 in netlink_macfdb_update_ctx() 3200 vid = dplane_ctx_mac_get_vlan(ctx); 3201 if (vid > 0) 3202 snprintf(vid_buf, sizeof(vid_buf), " VLAN %u", vid); 3203 else 3204 vid_buf[0] = '\0'; 3205 >>> CID 1496615: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "nfy & (8 /* 1 << 3 */)" is always 0 regardless of the values of its operands. This occurs as the logical first operand of "?:". 3206 zlog_debug("Tx %s family %s IF %s(%u)%s %sMAC %s dst %s nhg %u%s%s%s%s%s", 3207 nl_msg_type_to_str(cmd), nl_family_to_str(AF_BRIDGE), 3208 dplane_ctx_get_ifname(ctx), 3209 dplane_ctx_get_ifindex(ctx), vid_buf, 3210 dplane_ctx_mac_is_sticky(ctx) ? "sticky " : "", 3211 prefix_mac2str(mac, buf, sizeof(buf)), ** CID 1496614: Error handling issues (CHECKED_RETURN) /bgpd/bgp_evpn_mh.c: 1445 in bgp_evpn_local_es_up() ________________________________________________________________________________________________________ *** CID 1496614: Error handling issues (CHECKED_RETURN) /bgpd/bgp_evpn_mh.c: 1445 in bgp_evpn_local_es_up() 1439 /* generate EAD-EVI */ 1440 bgp_evpn_local_type1_evi_route_add(bgp, es); 1441 1442 /* generate EAD-ES */ 1443 build_evpn_type1_prefix(&p, BGP_EVPN_AD_ES_ETH_TAG, 1444 &es->esi, es->originator_ip); >>> CID 1496614: Error handling issues (CHECKED_RETURN) >>> Calling "bgp_evpn_type1_route_update" without checking return value (as is done elsewhere 4 out of 5 times). 1445 bgp_evpn_type1_route_update(bgp, es, NULL, &p); 1446 } 1447 1448 static void bgp_evpn_local_es_do_del(struct bgp *bgp, struct bgp_evpn_es *es) 1449 { 1450 struct bgp_evpn_es_evi *es_evi; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Notice: Telco call for 16:00 CET; 07:00 PT (tomorrow) Wednesday 5th is canceled
by Alistair Woodman 05 Aug '20

05 Aug '20

due to vacation time. (As discussed on the FRR weekly today) /a

1 0

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

04 Aug '20

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. 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 1 of 1 defect(s) ** CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) ________________________________________________________________________________________________________ *** CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) /zebra/zebra_rib.c: 2162 in rib_process_dplane_notify() 2156 2157 done: 2158 if (rn) 2159 route_unlock_node(rn); 2160 2161 /* Return context to dataplane module */ >>> CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) >>> Calling "dplane_ctx_fini" dereferences freed pointer "ctx". 2162 dplane_ctx_fini(&ctx); 2163 } 2164 2165 static void process_subq_nhg(struct listnode *lnode) 2166 { 2167 struct nhg_ctx *ctx = NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Pottential bugs RPKI States at FRR 7.3.1 (debian packages)
by Dewangga Alam 04 Aug '20

04 Aug '20

Hello! I am new at FRR, and trying to found a reference that indicated (bugs?) or miss configuration at version 7.3.1 using debian buster packages from deb.frrouting.org (http://deb.frrouting.org) Here’s our configuration: https://pastebin.com/xKE3AJij Already adjusted bgpd using rpki options, and when I restart frr service, the tagging was not working. > vtysh > sh bgp ipv4 103.241.24.0 BGP routing table entry for 103.241.24.0/24 Paths: (3 available, best #3, table default) Not advertised to any peer 38515 58820 103.28.75.36 from 103.28.75.0 (103.28.75.0) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.255 (103.28.74.255) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.129 (103.28.74.127) Origin IGP, localpref 5100, valid, internal, best (Router ID) Community: 38515:58820 Last update: Sat Aug 1 10:54:34 2020 The rpki states aren’t show, and when I paste the route-map configuration into vtysh, the loc-pref tag are valids and working. The full command pasted here: https://pastebin.com/n3VY4gNm Any hints to fix this issue ? Any helps are appreciated. Thanks in advance! Many thanks. -- Sent from Canary (https://canarymail.io)

2 1

zebra nexthop-tracking/reachability questions
by Mark Stapp 03 Aug '20

03 Aug '20

I've got a couple of questions about nexthop-tracking in zebra - these are a bit down in the details, but I thought I'd ask if any of the folks on the list have some insight... 1. the nht code makes a copy (mostly) of the route_entry that satisfies some client registration. the code copies all of the nexthops - even the recursive ones, even ones that are not ACTIVE. the code that sends nexthops to the nht client(s) has an rnh_nexthop_valid() function that is pretty strict about what will actually be sent. would it be reasonable to have the nht code capture only a list of the nexthops that are actually valid, that actually will be sent to the clients? 2. the show command for nht, ‘sho ip nht’, only shows the top-level nexthops - not the actual installed nexthops that, again, will be sent to the clients. would it be ok to change that, to try to have the show command show what will actually be sent to clients? 3. the route-map filtering in there also operates only on the top-level nexthops, not the exact ones that are "valid" and will be sent to clients. is that intentional, or should the route-map get a shot at the nexthops that the nht code would try to send? Thanks, Mark

1 0

Northbound meeting today is canceled
by Santosh P K 31 Jul '20

31 Jul '20

Hello All, I have a conflict today and hence will not be able to run northbound meeting today. Today’s meeting will be canceled. Thanks Santosh P K

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 28 Jul '20

28 Jul '20

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. 4 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 1496495: Error handling issues (CHECKED_RETURN) /zebra/zebra_dplane.c: 2539 in dplane_route_notif_update() ________________________________________________________________________________________________________ *** CID 1496495: Error handling issues (CHECKED_RETURN) /zebra/zebra_dplane.c: 2539 in dplane_route_notif_update() 2533 } 2534 2535 /* Capture info about the source of the notification, in 'ctx' */ 2536 dplane_ctx_set_notif_provider(new_ctx, 2537 dplane_ctx_get_notif_provider(ctx)); 2538 >>> CID 1496495: Error handling issues (CHECKED_RETURN) >>> Calling "dplane_update_enqueue" without checking return value (as is done elsewhere 9 out of 10 times). 2539 dplane_update_enqueue(new_ctx); 2540 2541 ret = ZEBRA_DPLANE_REQUEST_QUEUED; 2542 2543 done: 2544 return ret; ** CID 1496494: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_nb_config.c: 1221 in lib_vrf_zebra_l3vni_id_modify() ________________________________________________________________________________________________________ *** CID 1496494: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_nb_config.c: 1221 in lib_vrf_zebra_l3vni_id_modify() 1215 * if zebra vrf already mapped to different vni id. 1216 */ 1217 pn_dnode = yang_dnode_get_parent(args->dnode, "vrf"); 1218 if (pn_dnode) { 1219 vrfname = yang_dnode_get_string(pn_dnode, "./name"); 1220 vrf = vrf_lookup_by_name(vrfname); >>> CID 1496494: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "vrf", which is known to be "NULL". 1221 zvrf = zebra_vrf_lookup_by_id(vrf->vrf_id); 1222 if (zvrf->l3vni && zvrf->l3vni != vni) { 1223 zlog_debug( 1224 "vni %u cannot be configured as vni %u is already configured under the vrf", 1225 vni, zvrf->l3vni); 1226 return NB_ERR_VALIDATION; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Telco meeting status
by olivier.dugeon＠orange.com 24 Jul '20

24 Jul '20

Dear all, Following the last Telco meeting, I updated the Wiki page to reflect our new usage of GitHub Project management facilities: https://github.com/FRRouting/frr/wiki/FRR-Telco-SP-projects Regarding BGP-LS, there is already a #Telco channel on Slack with very few discussions. So, I propose to use this #Telco channel to discuss on-going development around BGP-LS. Cristain (in Cc:) started its internship within Orange one month ago. He'll join Slack soon. Cristian started to backport our old BGP-LS code to FRR. Please, interact with him through Slack to discuss how to organise the work and progress. As mentioned, I'll start 3 weeks vacations this evening. So, fill free to maintain or cancel the next Telco meeting in 2 weeks. Allistair will manage it. Finally, I'll push a preview of Link State PR as WIP. Look at the doxygen doc within link_state.h for details and usage. Enjoy your summer. Regards Olivier

1 0

BGP Link State code
by olivier.dugeon＠orange.com 17 Jul '20

17 Jul '20

Dear all, Many of you are interested by our very old code about BGP Link State. So, I decided to publish it, but ***AS IS*** more as a proof of concept rather than a running code. It is based on a old version of Quagga. I don't know if it compiles, if it runs ... As the code was unfortunately not versioned, I try to patch what seems the Quagga version from which the code was written to produce the git commit. But, I have not the time to check if the result compiles and if it is running. *Please, d**on't ask me for that*. As an old code, it is using old style. So, only new files are following FRR style. The repo is here: https://github.com/Orange-OpenSource/Quagga-TE/tree/BGP-LS The implementation is made of new files: - BGP-LS TLV definition: bgpd/bgp_ls.h - New Link State NLRI: bgpd/bgp_bgpls_nlri.c - Parser/Serializer: bgpd/bgp_ls_bgpls.c - BGP-LS Database: bgpd/bgp_lsdb.[c,h] - BGP API for OSPF-API: bgpd/bgp_api.[c,h], bgpd/bgp_ls_ospf.h - BGP Link State transcodage: bgpd/bgp_transcode.c - BGP to OSPF-API connection: bgpd/bgp_zbusclient.[c,h] At least the NLRI, TLV definition, parser / serializer and LSDB could be re-use easily. Of course all interaction with OSPF through OSPF API must be replaced by the new ZAPI Opaque message. And following files have been patched for integration: - bgpd/bgp_advertise.c, bgpd/bgp_aspath.c, bgpd/bgp_attr.|c,h], bgpd/bgp_btoa.c, bgpd/bgp_clist.c, bgpd/bgp_community.[c,h], bgpd/bgp_dump.c, bgpd/bgp_fsm.c, bgpd/bgp_main.c, bgpd/bgp_mplsvpn.c, bgpd/bgp_nexthop.c, bgpd/bgp_open.c, bgpd/bgp_packet.c, bgpd/bgp_route.c, bgpd/bgp_routemap.c, bgpd/bgp_table.c, bgpd/bgp_vty.c, bgpd/bgp_zebra.c, bgpd/bgpd.c, bgpd/bgpd.h Where takes place the huge part of difficulties in order to merge them into FRR. King regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0