Skip to content

Commit

Permalink
zebra: Fix use after free in debug path
Browse files Browse the repository at this point in the history
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
    FRRouting#1 0x555555705b54 in re_list_first zebra/rib.h:222
    FRRouting#2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248
    FRRouting#3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    FRRouting#4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    FRRouting#5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    FRRouting#6 0x7ffff7450e9c in thread_call lib/thread.c:1581
    FRRouting#7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    FRRouting#8 0x55555561a578 in main zebra/main.c:455
    FRRouting#9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
    FRRouting#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)
    FRRouting#1 0x7ffff739ccad in qfree lib/memory.c:129
    FRRouting#2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746
    FRRouting#3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240
    FRRouting#4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245
    FRRouting#5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
    FRRouting#6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
    FRRouting#7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
    FRRouting#8 0x7ffff7450e9c in thread_call lib/thread.c:1581
    FRRouting#9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
    FRRouting#10 0x55555561a578 in main zebra/main.c:455
    FRRouting#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)
    FRRouting#1 0x7ffff739cb98 in qcalloc lib/memory.c:110
    FRRouting#2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515
    FRRouting#3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576
    FRRouting#4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607
    FRRouting#5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012
    FRRouting#6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049
    FRRouting#7 0x55555571788b in rib_add zebra/zebra_rib.c:3327
    FRRouting#8 0x5555555e584a in connected_up zebra/connected.c:254
    FRRouting#9 0x5555555e42ff in connected_announce zebra/connected.c:94
    FRRouting#10 0x5555555e4fd3 in connected_update zebra/connected.c:195
    FRRouting#11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340
    FRRouting#12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213
    FRRouting#13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350
    FRRouting#14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941
    FRRouting#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>
  • Loading branch information
donaldsharp authored and chiragshah6 committed Oct 27, 2020
1 parent caf3f45 commit 72de2bf
Showing 1 changed file with 10 additions and 1 deletion.
11 changes: 10 additions & 1 deletion zebra/zebra_rib.c
Original file line number Diff line number Diff line change
Expand Up @@ -2263,9 +2263,18 @@ static void process_subq_route(struct listnode *lnode, uint8_t qindex)
rib_process(rnode);

if (IS_ZEBRA_DEBUG_RIB_DETAILED) {
struct route_entry *re = re_list_first(&dest->routes);
struct route_entry *re = NULL;
char buf[SRCDEST2STR_BUFFER];

/*
* rib_process may have freed the dest
* as part of the garbage collection. Let's
* prevent stupidity from happening.
*/
dest = rib_dest_from_rnode(rnode);
if (dest)
re = re_list_first(&dest->routes);

srcdest_rnode2str(rnode, buf, sizeof(buf));
zlog_debug("%s(%u:%u):%s: rn %p dequeued from sub-queue %u",
zvrf_name(zvrf), zvrf_id(zvrf), re ? re->table : 0, buf,
Expand Down

0 comments on commit 72de2bf

Please sign in to comment.