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

[WIP] zebra srv6 manager cleanup (1) #8

Open
wants to merge 60 commits into
base: master
Choose a base branch
from

Conversation

slankdev
Copy link
Owner

@slankdev slankdev commented Oct 10, 2020

Schedule

basic

  • kernel side の別のconfigurationした内容をzebraでparseして管理可能にする. 774ce57
  • connect label manager みたいな機能を作って srv6 info bcast をなくす.
    • bgpd から locator を指定するcli をbackport
    • locator set cliの backendを実装する.
      • srv6_manager_get_locator_chunk
      • srv6_manager_release_locator_chunk
      • zebra show segment-routing srv6 locator NAME
      • bgpd cliの裏側でそれを呼び出す. (get)
      • bgpd cliの裏側でそれを呼び出す. (release)
      • zebraで chunk 割り当てとその内容の非同期通知.
      • bgpd show bgp segment-routing srv6
      • compiler warningを全部なくす. (bgpd/bgp_zebra.c にあるはず)
      • srv6_locator_chunk の構造体を作ってそれでやる.
      • bgpd の実装を全て sharpd に移動する。
        • sharpd get srv6_locator_chunk
        • sharpd install srv6_function
        • sharpd uninstall srv6_function
        • sharpd release srv6_locator_chunk
        • show sharpd segment-routing srv6
        • process_srv6_locator_chunk を実装する.
      • zebra cli show segment-routing srv6 manager
      • zclientから release locator chunk ができるようにする.
      • bgpで指定して, locatorがなかった時の挙動を実装する.
    • zapi周りを作って終了.
      • function-add/del の zapiを消去する.
      • bcast のメカニズムも消去する.
  • srvvi0 を使った構成にする.
    • route-add zapiでは, oif を 0にしておくルールにする.

ボーナスステージ

  • kernel sideからの経路追加でzebraが壊れないような topotest
  • multi chunk 対応
    • locatorごとに static chunk という領域を作っておく...?

BGPd backport

router bgp 1
 address-family ipv4-vpn
  segment-routing srv6
   locator my_locator
  !
 exit-address-family
!

This commit is a part of FRRouting#5853 that add new cmd-node for SRv6 configuration.
This commit just add cmd-node and moving node cli only, acutual SRv6 config
command isn't added. (that is added later commit. of this branch)

new cli nodes:
* SR
* SRv6
* SRv6-locators
* SRv6-locator

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
Make seg6local_context2str function's prototype better.
This function is added on commit e496b42, and function
interface's considering wasn't enough.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of FRRouting#5853 works that add new nexthop's addional
object for SRv6 routing about seg6local route. Before this commit,
we can add MPLS info as additional object on nexthop.
This commit make it add more support about seg6local routes.

seg6local routes are ones of the LWT routing mechanism,
so configuration of seg6local routes is performed by
ZEBRA_ROUTE_SEND, it's same as MPLS configuration.

Real configuration implementation isn't implemented at this commit.
later commit add that. This commit add only nexthop additional object
and some misc functions.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of FRRouting#5853 works that add new structures of
SRv6-locator/function. This structure will be used by zebra and another
routing daemon to manage SRv6-locator/function. These structure will be
used by ZAPI datapath, encoder/decoder for ZAPI stream is also added by
this commit.

Real configure implementation isn't implemented at this commit.
later commit add real configure implementation. This commit add only
SRv6-locator/function's structures and misc functions.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of FRRouting#5853 works that add new ZAPI to configure SRv6
routing mechanism with seg6local LTW route.

NEW-ZAPIs:
* ZEBRA_SRV6_LOCATOR_ADD
* ZEBRA_SRV6_LOCATOR_DELETE
* ZEBRA_SRV6_FUNCTION_ADD
* ZEBRA_SRV6_FUNCTION_DELETE

If user or routing daemon create new SRv6-locator or function on zebra,
zserv(zebra) notifiy that creation context to each zclient. zclient can know
this notification some SRv6-locator or function are created on zebra. And,
zclient can add/delete SRv6-locator and function to call this apis. Thus in
this ZAPI, direction (from zclient to zserv or else) is important.

This commit also make zebra data-plane maanger to support seg6local
route. so after this commit. Zebra can support to configure seg6local route
as SRv6 local function.

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of FRRouting#5853 works that add new clis to configure SRv6
dataplane. Following clis are added on this commit.

- "show segment-routing srv6 sid [json]"
- "show segment-routing srv6 locator [json]"
- "show runnning-config" (make it to print srv6 configuration)

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of FRRouting#5853 works.
This commit add new topotest to verify SRv6-manager's functionality.
Following tests are performed on this topotest.

- check that SRv6-locator is set correctly
- check that default SRv6-function locator is set correctly
- check that SRv6-function is installed as ipv6 route correctly

Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
@slankdev slankdev changed the title [WIP] zebra srv6 manager cleanup 1 [WIP] zebra srv6 manager cleanup (1) Oct 10, 2020
@slankdev slankdev force-pushed the slankdev-zebra-srv6-manager-cleanup-1 branch from 85f9123 to 3cf27b2 Compare October 11, 2020 07:47
slankdev pushed a commit that referenced this pull request Dec 6, 2020
When zebra is running with debugs turned on there
is a use after free reported by the address sanitizer:

2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing
2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3
=================================================================
==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8
READ of size 8 at 0x608000011d28 thread T0
    #0 0x555555705ab5 in re_list_const_first zebra/rib.h:222
    #1 0x555555705b54 in re_list_first zebra/rib.h:222
    #2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248
    #3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #6 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #8 0x55555561a578 in main zebra/main.c:455
    #9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
    #10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429)
0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78)
freed by thread T0 here:
    #0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
    #1 0x7ffff739ccad in qfree lib/memory.c:129
    #2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746
    #3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240
    #4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245
    #5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    #6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    #7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    #8 0x7ffff7450e9c in thread_call lib/thread.c:1581
    #9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    #10 0x55555561a578 in main zebra/main.c:455
    #11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
    #0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
    #1 0x7ffff739cb98 in qcalloc lib/memory.c:110
    #2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515
    #3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576
    #4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607
    #5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012
    #6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049
    #7 0x55555571788b in rib_add zebra/zebra_rib.c:3327
    #8 0x5555555e584a in connected_up zebra/connected.c:254
    #9 0x5555555e42ff in connected_announce zebra/connected.c:94
    #10 0x5555555e4fd3 in connected_update zebra/connected.c:195
    #11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340
    #12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213
    #13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350
    #14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941
    #15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402
    FRRouting#16 0x7ffff7450e9c in thread_call lib/thread.c:1581
    FRRouting#17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    FRRouting#18 0x55555561a578 in main zebra/main.c:455
    FRRouting#19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first

This is happening because we are using the dest pointer after a call into
rib_gc_dest.  In process_subq_route, we call rib_process() and if the
dest is deleted dest pointer is now garbage.  We must reload the
dest pointer in this case.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
slankdev pushed a commit that referenced this pull request Dec 6, 2020
We are using data after it has been freed and handed back to the
OS.
Address Sanitizer output:

error	23-Nov-2020 18:53:57	ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55f825998f58 bp 0x7fffa5b0f5b0 sp 0x7fffa5b0f5a0
error	23-Nov-2020 18:53:57	READ of size 4 at 0x631000024838 thread T0
error	23-Nov-2020 18:53:57	    #0 0x55f825998f57 in lde_imsg_compose_parent_sync ldpd/lde.c:226
error	23-Nov-2020 18:53:57	    #1 0x55f8259ca9ed in vlog ldpd/log.c:48
error	23-Nov-2020 18:53:57	    #2 0x55f8259cb1c8 in log_info ldpd/log.c:102
error	23-Nov-2020 18:53:57	    #3 0x55f82599e841 in lde_shutdown ldpd/lde.c:208
error	23-Nov-2020 18:53:57	    #4 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #5 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #6 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #7 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #8 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57	    #9 0x55f825982579 in _start (/usr/lib/frr/ldpd+0xb3579)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error	23-Nov-2020 18:53:57	freed by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4d7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error	23-Nov-2020 18:53:57	    #1 0x55f82599e830 in lde_shutdown ldpd/lde.c:206
error	23-Nov-2020 18:53:57	    #2 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error	23-Nov-2020 18:53:57	    #3 0x55f825ac3815 in thread_call lib/thread.c:1681
error	23-Nov-2020 18:53:57	    #4 0x55f825998d5e in lde ldpd/lde.c:160
error	23-Nov-2020 18:53:57	    #5 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #6 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57
error	23-Nov-2020 18:53:57	previously allocated by thread T0 here:
error	23-Nov-2020 18:53:57	    #0 0x7fe3f8a4dd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error	23-Nov-2020 18:53:57	    #1 0x55f825998cb7 in lde ldpd/lde.c:151
error	23-Nov-2020 18:53:57	    #2 0x55f82598a289 in main ldpd/ldpd.c:320
error	23-Nov-2020 18:53:57	    #3 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	23-Nov-2020 18:53:57

The fix is to put this in global space.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
slankdev pushed a commit that referenced this pull request Dec 6, 2020
error	26-Nov-2020 14:35:02	ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55cefae977e9 bp 0x7ffdd3546860 sp 0x7ffdd3546850
error	26-Nov-2020 14:35:02	READ of size 4 at 0x631000024838 thread T0
error	26-Nov-2020 14:35:02	    #0 0x55cefae977e8 in ldpe_imsg_compose_parent_sync ldpd/ldpe.c:256
error	26-Nov-2020 14:35:02	    #1 0x55cefae9ab13 in vlog ldpd/log.c:53
error	26-Nov-2020 14:35:02	    #2 0x55cefae9b21f in log_info ldpd/log.c:102
error	26-Nov-2020 14:35:02	    #3 0x55cefae96eae in ldpe_shutdown ldpd/ldpe.c:237
error	26-Nov-2020 14:35:02	    #4 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585
error	26-Nov-2020 14:35:02	    #5 0x55cefaf93875 in thread_call lib/thread.c:1681
error	26-Nov-2020 14:35:02	    #6 0x55cefae97304 in ldpe ldpd/ldpe.c:136
error	26-Nov-2020 14:35:02	    #7 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #8 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	26-Nov-2020 14:35:02	    #9 0x55cefae525e9 in _start (/usr/lib/frr/ldpd+0xb35e9)
error	26-Nov-2020 14:35:02
error	26-Nov-2020 14:35:02	0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error	26-Nov-2020 14:35:02	freed by thread T0 here:
error	26-Nov-2020 14:35:02	    #0 0x7f4ef21e37a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error	26-Nov-2020 14:35:02	    #1 0x55cefae96e91 in ldpe_shutdown ldpd/ldpe.c:234
error	26-Nov-2020 14:35:02	    #2 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585
error	26-Nov-2020 14:35:02	    #3 0x55cefaf93875 in thread_call lib/thread.c:1681
error	26-Nov-2020 14:35:02	    #4 0x55cefae97304 in ldpe ldpd/ldpe.c:136
error	26-Nov-2020 14:35:02	    #5 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #6 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error	26-Nov-2020 14:35:02
error	26-Nov-2020 14:35:02	previously allocated by thread T0 here:
error	26-Nov-2020 14:35:02	    #0 0x7f4ef21e3d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error	26-Nov-2020 14:35:02	    #1 0x55cefae9725d in ldpe ldpd/ldpe.c:127
error	26-Nov-2020 14:35:02	    #2 0x55cefae5a2e2 in main ldpd/ldpd.c:322
error	26-Nov-2020 14:35:02	    #3 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Clean this problem up in the same way as the previous commit

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
slankdev pushed a commit that referenced this pull request Oct 9, 2021
Our Address Sanitizer CI is finding this issue:
error	09-Oct-2019 19:28:33	r4: bgpd triggered an exception by AddressSanitizer
error	09-Oct-2019 19:28:33	ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540
error	09-Oct-2019 19:28:33	READ of size 1 at 0x7ffdd425b060 thread T0
error	09-Oct-2019 19:28:33	    #0 0x68575e in prefix_cmp lib/prefix.c:776
error	09-Oct-2019 19:28:33	    #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230
error	09-Oct-2019 19:28:33	    #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520
error	09-Oct-2019 19:28:33	    #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071
error	09-Oct-2019 19:28:33	    #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736
error	09-Oct-2019 19:28:33	    #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237
error	09-Oct-2019 19:28:33	    #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315
error	09-Oct-2019 19:28:33	    #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598
error	09-Oct-2019 19:28:33	    #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274
error	09-Oct-2019 19:28:33	    #9 0x6b9f54 in thread_call lib/thread.c:1531
error	09-Oct-2019 19:28:33	    #10 0x657037 in frr_run lib/libfrr.c:1052
error	09-Oct-2019 19:28:33	    #11 0x42d268 in main bgpd/bgp_main.c:486
error	09-Oct-2019 19:28:33	    #12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
error	09-Oct-2019 19:28:33	    #13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8)
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame
error	09-Oct-2019 19:28:33	    #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103
error	09-Oct-2019 19:28:33
error	09-Oct-2019 19:28:33	  This frame has 5 object(s):
error	09-Oct-2019 19:28:33	    [32, 36) 'label'
error	09-Oct-2019 19:28:33	    [96, 108) 'rd_as'
error	09-Oct-2019 19:28:33	    [160, 172) 'rd_ip'
error	09-Oct-2019 19:28:33	    [224, 240) 'prd' <== Memory access at offset 240 overflows this variable
error	09-Oct-2019 19:28:33	    [288, 336) 'p'
error	09-Oct-2019 19:28:33	HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
error	09-Oct-2019 19:28:33	      (longjmp and C++ exceptions *are* supported)
error	09-Oct-2019 19:28:33	SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp
error	09-Oct-2019 19:28:33	Shadow bytes around the buggy address:
error	09-Oct-2019 19:28:33	  0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3
error	09-Oct-2019 19:28:33	  0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
error	09-Oct-2019 19:28:33	  0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2
error	09-Oct-2019 19:28:33	=>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2
error	09-Oct-2019 19:28:33	  0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00
error	09-Oct-2019 19:28:33	  0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error	09-Oct-2019 19:28:33	  0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4
error	09-Oct-2019 19:28:33	  0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	  0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00
error	09-Oct-2019 19:28:33	Shadow byte legend (one shadow byte represents 8 application bytes):
error	09-Oct-2019 19:28:33	  Addressable:           00
error	09-Oct-2019 19:28:33	  Partially addressable: 01 02 03 04 05 06 07
error	09-Oct-2019 19:28:33	  Heap left redzone:       fa
error	09-Oct-2019 19:28:33	  Heap right redzone:      fb
error	09-Oct-2019 19:28:33	  Freed heap region:       fd
error	09-Oct-2019 19:28:33	  Stack left redzone:      f1
error	09-Oct-2019 19:28:33	  Stack mid redzone:       f2
error	09-Oct-2019 19:28:33	  Stack right redzone:     f3
error	09-Oct-2019 19:28:33	  Stack partial redzone:   f4
error	09-Oct-2019 19:28:33	  Stack after return:      f5
error	09-Oct-2019 19:28:33	  Stack use after scope:   f8
error	09-Oct-2019 19:28:33	  Global redzone:          f9
error	09-Oct-2019 19:28:33	  Global init order:       f6
error	09-Oct-2019 19:28:33	  Poisoned by user:        f7
error	09-Oct-2019 19:28:33	  Container overflow:      fc
error	09-Oct-2019 19:28:33	  Array cookie:            ac
error	09-Oct-2019 19:28:33	  Intra object redzone:    bb
error	09-Oct-2019 19:28:33	  ASan internal:           fe
error	09-Oct-2019 19:28:36	r3: Daemon bgpd not running

This is the result of this code pattern in rfapi/rfapi_import.c:

prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd,
	   (struct prefix *)prd))

Effectively prd or vnc.import.rd are `struct prefix_rd` which
are being typecast to a `struct prefix`.  Not a big deal except commit
1315d74 modified the prefix_cmp
function to allow for a sorted prefix_cmp.  In prefix_cmp
we were looking at the offset and shift.  In the case
of vnc we were passing a prefix length of 64 which is the exact length of
the remaining data structure for struct prefix_rd.  So we calculated
a offset of 8 and a shift of 0.  The data structures for the prefix
portion happened to be equal to 64 bits of data. So we checked that
with the memcmp got a 0 and promptly read off the end of the data
structure for the numcmp.  The fix is if shift is 0 that means thei
the memcmp has checked everything and there is nothing to do.

Please note: We will still crash if we set the prefixlen > then
~312 bits currently( ie if the prefixlen specifies a bit length
longer than the prefix length ).  I do not think there is
anything to do here( nor am I sure how to correct this either )
as that we are going to have some severe problems when we muck
up the prefixlen.

Fixes: FRRouting#5025
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant