August 2024 - dev - lists.frrouting.org

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

29 Aug '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 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 4 of 4 defect(s) ** CID 1599394: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 82 in bgp_reads_on() ________________________________________________________________________________________________________ *** CID 1599394: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 82 in bgp_reads_on() 76 void bgp_reads_on(struct peer_connection *connection) 77 { 78 struct frr_pthread *fpt = bgp_pth_io; 79 assert(fpt->running); 80 81 assert(connection->status != Deleted); >>> CID 1599394: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 82 assert(connection->ibuf); 83 assert(connection->fd); 84 assert(connection->ibuf_work); 85 assert(connection->obuf); 86 assert(!connection->t_connect_check_r); 87 assert(!connection->t_connect_check_w); ** CID 1599393: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 53 in bgp_writes_on() ________________________________________________________________________________________________________ *** CID 1599393: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 53 in bgp_writes_on() 47 struct frr_pthread *fpt = bgp_pth_io; 48 49 assert(fpt->running); 50 51 assert(connection->status != Deleted); 52 assert(connection->obuf); >>> CID 1599393: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 53 assert(connection->ibuf); 54 assert(connection->ibuf_work); 55 assert(!connection->t_connect_check_r); 56 assert(!connection->t_connect_check_w); 57 assert(connection->fd); 58 ** CID 1599392: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_fsm.c: 524 in bgp_holdtime_timer() ________________________________________________________________________________________________________ *** CID 1599392: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_fsm.c: 524 in bgp_holdtime_timer() 518 * events on the peer. If we have incoming 519 * data on the peers inq, let's give the system a chance 520 * to handle that data. This can be especially true 521 * for systems where we are heavily loaded for one 522 * reason or another. 523 */ >>> CID 1599392: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 524 inq_count = atomic_load_explicit(&connection->ibuf->count, 525 memory_order_relaxed); 526 if (inq_count) 527 BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer, 528 peer->v_holdtime); 529 ** CID 1599391: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_rib.c: 4416 in rib_add_multipath() ________________________________________________________________________________________________________ *** CID 1599391: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_rib.c: 4416 in rib_add_multipath() 4410 ZEBRA_IFA_NOPREFIXROUTE)) { 4411 zebra_nhg_free(n); 4412 zebra_rib_route_entry_free(re); 4413 return -1; 4414 } 4415 >>> CID 1599391: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "ng". 4416 if (ifp->ifindex == ng->nexthop->ifindex) 4417 re->type = ZEBRA_ROUTE_CONNECT; 4418 } 4419 } 4420 4421 ret = rib_add_multipath_nhe(afi, safi, p, src_p, re, n, startup); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

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

28 Aug '24

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 1599385: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_routemap.c: 1084 in route_match_vni() ________________________________________________________________________________________________________ *** CID 1599385: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_routemap.c: 1084 in route_match_vni() 1078 && (evp->prefix.route_type != BGP_EVPN_AD_ROUTE 1079 && evp->prefix.route_type != BGP_EVPN_MAC_IP_ROUTE 1080 && evp->prefix.route_type != BGP_EVPN_IP_PREFIX_ROUTE)) 1081 return RMAP_NOOP; 1082 1083 for (label_cnt = 0; label_cnt < BGP_MAX_LABELS && >>> CID 1599385: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "path" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1084 label_cnt < BGP_PATH_INFO_NUM_LABELS(path); 1085 label_cnt++) { 1086 if (vni == label2vni(&path->extra->labels->label[label_cnt])) 1087 return RMAP_MATCH; 1088 } 1089 ** CID 1599384: (USE_AFTER_FREE) /bgpd/bgp_route.c: 4883 in bgp_update() /bgpd/bgp_route.c: 4965 in bgp_update() /bgpd/bgp_route.c: 4937 in bgp_update() /bgpd/bgp_route.c: 4909 in bgp_update() /bgpd/bgp_route.c: 5389 in bgp_update() ________________________________________________________________________________________________________ *** CID 1599384: (USE_AFTER_FREE) /bgpd/bgp_route.c: 4883 in bgp_update() 4877 bgp_path_info_labels_same(pi, bgp_labels.label, 4878 bgp_labels.num_labels))) { 4879 if (get_active_bdc_from_pi(pi, afi, safi) && 4880 peer->sort == BGP_PEER_EBGP && 4881 CHECK_FLAG(pi->flags, BGP_PATH_HISTORY)) { 4882 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4883 bgp_debug_rdpfxpath2str( 4884 afi, safi, prd, p, label, 4885 num_labels, addpath_id ? 1 : 0, 4886 addpath_id, evpn, pfx_buf, 4887 sizeof(pfx_buf)); 4888 zlog_debug("%pBP rcvd %s", peer, /bgpd/bgp_route.c: 4965 in bgp_update() 4959 */ 4960 bgp_aggregate_decrement(bgp, p, pi, afi, safi); 4961 } 4962 4963 /* Received Logging. */ 4964 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4965 bgp_debug_rdpfxpath2str(afi, safi, prd, p, label, 4966 num_labels, addpath_id ? 1 : 0, 4967 addpath_id, evpn, pfx_buf, 4968 sizeof(pfx_buf)); 4969 zlog_debug("%pBP rcvd %s", peer, pfx_buf); 4970 } /bgpd/bgp_route.c: 4937 in bgp_update() 4931 return; 4932 } 4933 4934 /* Withdraw/Announce before we fully processed the withdraw */ 4935 if (CHECK_FLAG(pi->flags, BGP_PATH_REMOVED)) { 4936 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4937 bgp_debug_rdpfxpath2str( 4938 afi, safi, prd, p, label, num_labels, 4939 addpath_id ? 1 : 0, addpath_id, evpn, 4940 pfx_buf, sizeof(pfx_buf)); 4941 zlog_debug( 4942 "%pBP rcvd %s, flapped quicker than processing", /bgpd/bgp_route.c: 4909 in bgp_update() 4903 "%pBP rcvd UPDATE w/ attr: %s", 4904 peer, 4905 peer->rcvd_attr_str); 4906 peer->rcvd_attr_printed = 1; 4907 } 4908 >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4909 bgp_debug_rdpfxpath2str( 4910 afi, safi, prd, p, label, 4911 num_labels, addpath_id ? 1 : 0, 4912 addpath_id, evpn, pfx_buf, 4913 sizeof(pfx_buf)); 4914 zlog_debug( /bgpd/bgp_route.c: 5389 in bgp_update() 5383 if (!peer->rcvd_attr_printed) { 5384 zlog_debug("%pBP rcvd UPDATE w/ attr: %s", peer, 5385 peer->rcvd_attr_str); 5386 peer->rcvd_attr_printed = 1; 5387 } 5388 >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 5389 bgp_debug_rdpfxpath2str(afi, safi, prd, p, label, num_labels, 5390 addpath_id ? 1 : 0, addpath_id, evpn, 5391 pfx_buf, sizeof(pfx_buf)); 5392 zlog_debug("%pBP rcvd UPDATE about %s -- DENIED due to: %s", 5393 peer, pfx_buf, reason); 5394 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

EVPN Query
by Atul Chowdhry 27 Aug '24

27 Aug '24

Hi Guys, I am looking at the given below function zebra_evpn_mac_is_static in zebra/zebra_evpn_mac.h file. /* if the mac has been added of a mac-route from the peer * or if it is being referenced by a neigh added by the * peer we cannot let it age out i.e. we set the static bit * in the dataplane */ static inline bool zebra_evpn_mac_is_static(struct zebra_mac *mac) { return ((mac->flags & ZEBRA_MAC_ALL_PEER_FLAGS) || mac->sync_neigh_cnt); } Is the use of ZEBRA_MAC_ALL_PEER_FLAGS correct here ? I feel that it should be ZEBRA_MAC_ES_PEER_ACTIVE instead. The current code is leading to creation of static mac on mac originating peer also since it will have the ZEBRA_MAC_ES_PEER_PROXY flag set. Rgds Atul

1 0

FRR Release 10.1
by Jafar Al-Gharaibeh 08 Aug '24

08 Aug '24

Dear FRR Community, We are pleased to announce FRR release 10.1. Release notes are available at: https://frrouting.org/release https://github.com/FRRouting/frr/releases Please let us know if you see any issues. Cheers, The FRR Development Team!

1 0

Re: [dev] BMP Issue in FRR 10.0
by Donatas Abraitis 07 Aug '24

07 Aug '24

You are checking the master branch (development) documentation. You should use https://docs.frrouting.org/en/stable-10.0/bmp.html. On Tue, Jul 23, 2024 at 3:08 PM Boris Hassanov via dev < dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Boris Hassanov <bhassanov(a)yahoo.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2024 17:12:18 +0000 (UTC) > Subject: BMP Issue in FRR 10.0 > Hi all, > > During the testing I found strange BMP issue. RFC 7854 describes several > types of BMP messages, one of them is Stats Report ( > https://www.rfc-editor.org/rfc/rfc7854#page-13) > > The FRR documentation (. > https://docs.frrouting.org/en/latest/bmp.html#bmp-session-configuration ) > explicitly says: > " > > - > > the following statistics codes are implemented: > - > > 0: count of prefixes rejected > - > > 2: count of duplicate prefix withdrawals > - > > 3: count of prefixes with loop in cluster id > - > > 4: count of prefixes with loop in AS-path > - > > 5: count of prefixes with loop in originator > - > > 7: count of routes in adj-rib-in > - > > 8: count of routes in Loc-RIB > - > > 11: count of updates subjected to RFC 7607 > <https://datatracker.ietf.org/doc/html/rfc7607.html> “treat as > withdrawal” handling due to errors > - > > 65531: *experimental* count of prefixes rejected due to invalid > next-hop > > Note that stat items 3, 4 and 5 are specified to count updates, but > FRR implements them as prefix-based counters. > > " > The issue is that I do not see Stats Types 7 and 8 in the BMP message from > FRR towards BMP collector (goBMP in my test setup): > > [image: Inline image] > > > There are only 7 statistic types and no statistic codes 7 and 8. > > Is this a bug or I missed something in BMP config ? > > Here is the BMP config oof the FRR for the reference: > > bmp targets ubuntu-BMP > > bmp stats interval 300 > > bmp monitor ipv4 unicast pre-policy > > bmp monitor ipv4 unicast loc-rib > > bmp connect 10.30.131.101 port 5050 min-retry 30000 max-retry 3000 > source-interface eth2 > > exit > > FRR1# sh ver > > FRRouting 10.0_git (FRR1) on Linux(5.15.0-102-generic). > > Thank you in advance for the clarification. > > > SY, > Boris > > > > > > > > > ---------- Forwarded message ---------- > From: Boris Hassanov via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2024 17:12:18 +0000 (UTC) > Subject: [dev] BMP Issue in FRR 10.0 > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Donatas

2 1