Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bgpd: rfapi adds paths without destination "net" pointers to bgp rib #17377

Open
2 tasks done
mxyns opened this issue Nov 7, 2024 · 0 comments
Open
2 tasks done

bgpd: rfapi adds paths without destination "net" pointers to bgp rib #17377

mxyns opened this issue Nov 7, 2024 · 0 comments
Labels
triage Needs further investigation

Comments

@mxyns
Copy link
Contributor

mxyns commented Nov 7, 2024

Description

The bgp rfapi topotests use rfapi features that generate and add paths to the BGP RIB.
The path generated have NULL net pointers (no destination) which I believe is invalid.

Version

frr-10.3-dev-307-g4c525a47c8

How to reproduce

  1. checkout master : git describe => frr-10.3-dev-307-g4c525a47c8
  2. add the following code at line 541 of bgp_mpath.c (in bgp_path_info_mpath_update)
bgp_dest_lock_node(cur_iterator->net);
bgp_dest_unlock_node(cur_iterator->net);
  1. build and install frr
  2. run rfapi test sudo rm -rf /tmp/topotests/ && sudo -E python3 -m pytest -s -v -k *rfapi*
  3. test fails and core dump is found in r3
  4. gdb the core file gdb /usr/lib/frr/bgpd $(ls /tmp/topotests/bgp_rfapi_basic_sanity_config2.test_bgp_rfapi_basic_sanity_config2/r3/bgpd_core-* | head -1)
  5. bt gives the same crash as on my branch where cur_iterator->net is NULL
#0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=135726069107136) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=11, threadid=135726069107136) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=135726069107136, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
#3  0x00007b7130042476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#4  0x00007b71305487b6 in core_handler (signo=11, siginfo=0x7fff6e957db0, context=0x7fff6e957c80) at lib/sigevent.c:268
#5  <signal handler called>
#6  0x0000609c3466ca14 in route_lock_node (node=0x0) at ./lib/table.h:232
#7  0x0000609c3466cc31 in bgp_dest_lock_node (dest=0x0) at bgpd/bgp_table.c:55
#8  0x0000609c345f14ae in bgp_path_info_mpath_update (bgp=0x609c35306d30, dest=0x609c35332860, new_best=0x609c35332980, old_best=0x0, num_candidates=1, mpath_cfg=0x609c35308242) at bgpd/bgp_mpath.c:542
#9  0x0000609c3462eccb in bgp_best_selection (bgp=0x609c35306d30, dest=0x609c35332860, mpath_cfg=0x609c35308242, result=0x7fff6e958640, afi=AFI_IP, safi=SAFI_MPLS_VPN) at bgpd/bgp_route.c:3333
#10 0x0000609c3462fb37 in bgp_process_main_one (bgp=0x609c35306d30, dest=0x609c35332860, afi=AFI_IP, safi=SAFI_MPLS_VPN) at bgpd/bgp_route.c:3743
#11 0x0000609c346308fb in bgp_process_wq (wq=0x609c35306520, data=0x609c3532afd0) at bgpd/bgp_route.c:4041
#12 0x00007b7130575f0e in work_queue_run (thread=0x7fff6e9587f0) at lib/workqueue.c:282
--Type <RET> for more, q to quit, c to continue without paging--
#13 0x00007b7130563c9e in event_call (thread=0x7fff6e9587f0) at lib/event.c:1996
#14 0x00007b71304dddc2 in frr_run (master=0x609c34aeac00) at lib/libfrr.c:1232
#15 0x0000609c34576984 in main (argc=7, argv=0x7fff6e958a78) at bgpd/bgp_main.c:555

This happens after the following command in parse on r3 debug rfapi-dev register vn 10.0.0.2 un 2.2.2.2 prefix 22.22.22.0/24 lifetime -1

I ran a lookup in the bgpd code for anything matching info_make\([\w,->\s\n]*, NULL\) (all info_make calls with a NULL dest pointer). I found two occurrences of this in rfapi_import.c@447 and rfapi.c@1012. I did not find the code that sets the backpointer of bpi->net there.

I'm not sure about the rfapi usecase and if this is expected behaviour or not but based on what you told me before about bgp_path_info it seems like not ?

Expected behavior

have the bpi->net set to the related bgp_dest in rfapi commands

Actual behavior

crash (see reproduce steps)

Additional context

No response

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@mxyns mxyns added the triage Needs further investigation label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Needs further investigation
Projects
None yet
Development

No branches or pull requests

1 participant