Write a test for event_add(ev,NULL) on an event with an existing timeout #5

nmathewson · 2012-03-27T03:12:00Z

I thought that this call would leave the event pending, but remove its timeout entirely. Looking at the code, I'm not sure this is what we do. We should probably document this if so; it is surprising behavior.

nmathewson · 2012-08-23T15:43:32Z

The confusion here seems to be behind #16.

nmathewson · 2012-11-16T23:37:01Z

Ok, I added a new event_remove_timer() function, with a test.

$ https-client with -url http://127.1:81 -retries 2 ================== WARNING: ThreadSanitizer: data race (pid=19704) Write of size 4 at 0x7d480000b500 by thread T1 (mutexes: write M12): #0 evhttp_connection_reset_ ../http.c:1286 (https-client+0x000000451ef6) #1 evhttp_connection_cb_cleanup ../http.c:1319 (https-client+0x0000004520a5) #2 evhttp_connection_cb ../http.c:1522 (https-client+0x000000452e94) libevent#3 bufferevent_run_eventcb_ ../bufferevent.c:279 (https-client+0x00000041c3a7) libevent#4 bufferevent_writecb ../bufferevent_sock.c:263 (https-client+0x000000425295) libevent#5 event_persist_closure ../event.c:1549 (https-client+0x00000042d132) libevent#6 event_process_active_single_queue ../event.c:1608 (https-client+0x00000042d51a) libevent#7 event_process_active ../event.c:1707 (https-client+0x00000042e010) libevent#8 event_base_loop ../event.c:1930 (https-client+0x00000042ece0) libevent#9 evbase_thread ../sample/https-client.c:57 (https-client+0x00000040b8ec) libevent#10 <null> <null> (libtsan.so.0+0x000000023559) Previous read of size 4 at 0x7d480000b500 by main thread: #0 evhttp_connected ../http.c:406 (https-client+0x00000044f27c) #1 evhttp_make_request ../http.c:2541 (https-client+0x0000004566a7) #2 main ../sample/https-client.c:456 (https-client+0x00000040c67a) Location is heap block of size 384 at 0x7d480000b400 allocated by main thread: #0 calloc <null> (libtsan.so.0+0x0000000259ad) #1 event_mm_calloc_ ../event.c:3428 (https-client+0x000000437655) #2 evhttp_connection_base_bufferevent_new ../http.c:2256 (https-client+0x0000004552f5) libevent#3 main ../sample/https-client.c:409 (https-client+0x00000040c452) Mutex M12 (0x7d0c00029250) created at: #0 pthread_mutex_init <null> (libtsan.so.0+0x000000027e15) #1 evthread_posix_lock_alloc ../evthread_pthread.c:53 (https-client+0x00000044e5c5) #2 bufferevent_enable_locking_ ../bufferevent.c:827 (https-client+0x00000041e9ad) libevent#3 bufferevent_init_common_ ../bufferevent.c:331 (https-client+0x00000041c6a2) libevent#4 bufferevent_socket_new ../bufferevent_sock.c:357 (https-client+0x0000004255bc) libevent#5 main ../sample/https-client.c:392 (https-client+0x00000040c3a0) Thread T1 (tid=19706, running) created by main thread at: #0 pthread_create <null> (libtsan.so.0+0x000000027414) #1 main ../sample/https-client.c:377 (https-client+0x00000040c325) SUMMARY: ThreadSanitizer: data race ../http.c:1286 evhttp_connection_reset_ Refs: libevent#258

On FreeBSD with kqueue there is a call to evthread_debug_lock_mark_unlocked() during event_base_free(), that will fail with an assert because of unmatched "held_by", fix this by reseting lock callbacks to NULL before event_base_free(). Trace: bufferevent/bufferevent_pair_release_lock: [warn] Trying to disable lock functions after they have been set up will probaby not work. [warn] Trying to disable lock functions after they have been set up will probaby not work. FAIL libevent/test/regress_bufferevent.c:259: lock: lock error[err] libevent/evthread.c:277: Assertion lock->held_by == me failed in evthread_debug_lock_mark_unlocked [New Thread 802006400 (LWP 100070/regress)] Program received signal SIGABRT, Aborted. [Switching to Thread 802006400 (LWP 100070/regress)] 0x000000080167d6ca in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080167d6ca in thr_kill () from /lib/libc.so.7 #1 0x0000000801752149 in abort () from /lib/libc.so.7 #2 0x00000000004dff44 in event_exit (errcode=-559030611) at libevent/log.c:105 #3 0x00000000004e053c in event_errx (eval=-559030611, fmt=0x5182cc "%s:%d: Assertion %s failed in %s") at libevent/log.c:162 #4 0x00000000004d9954 in evthread_debug_lock_mark_unlocked (mode=0, lock=0x802017060) at libevent/evthread.c:277 #5 0x00000000004d909a in debug_lock_unlock (mode=0, lock_=0x802017060) at libevent/evthread.c:290 #6 0x00000000004e132c in evsig_dealloc_ (base=0x80201e300) at libevent/signal.c:434 #7 0x00000000004e36c1 in kq_dealloc (base=0x80201e300) at libevent/kqueue.c:435 #8 0x00000000004c9a44 in event_base_free_ (base=0x80201e300, run_finalizers=1) at libevent/event.c:855 #9 0x00000000004c931a in event_base_free (base=0x0) at libevent/event.c:887 #10 0x0000000000452657 in lock_unlock_free_thread_cbs () at libevent/test/regress_bufferevent.c:279 #11 0x0000000000452621 in free_lock_unlock_profiler (data=0x8020170a0) at libevent/test/regress_bufferevent.c:317 #12 0x000000000044bc8f in test_bufferevent_pair_release_lock (arg=0x8020170a0) at libevent/test/regress_bufferevent.c:334 #13 0x00000000004b2288 in testcase_run_bare_ (testcase=0x737660) at libevent/test/tinytest.c:105 #14 0x00000000004b1e72 in testcase_run_one (group=0x738c90, testcase=0x737660) at libevent/test/tinytest.c:252 #15 0x00000000004b2930 in tinytest_main (c=3, v=0x7fffffffead0, groups=0x738c20) at libevent/test/tinytest.c:434 #16 0x00000000004982fe in main (argc=3, argv=0x7fffffffead0) at libevent/test/regress_main.c:459 (gdb) f 4 #4 0x00000000004d9954 in evthread_debug_lock_mark_unlocked (mode=0, lock=0x802017060) at libevent/evthread.c:277 277 EVUTIL_ASSERT(lock->held_by == me); Current language: auto; currently minimal (gdb) p lock $1 = (struct debug_lock *) 0x802017060 (gdb) p lock->held_by $2 = 0 (gdb) p me $3 = 34393318400

…l-lock case Sample bt: (gdb) bt #0 0x00000000004a95d2 in evthread_setup_global_lock_ (lock_=0x0, locktype=0, enable_locks=1) #1 0x00000000004afbc7 in evsig_global_setup_locks_ (enable_locks=1) at signal.c:475 #2 0x00000000004a5da8 in event_global_setup_locks_ (enable_locks=1) at event.c:3838 #3 0x00000000004a8983 in evthread_set_lock_callbacks (cbs=0x7fffffffdde0) at evthread.c:129 #4 0x0000000000445a8f in use_lock_unlock_profiler () at regress_bufferevent.c:306 #5 0x0000000000445af2 in test_bufferevent_pair_release_lock (arg=0x70e710) at regress_bufferevent.c:327 #6 0x000000000048c9a8 in testcase_run_bare_ (testcase=0x6fdc10 <bufferevent_testcases+80>) at tinytest.c:105 #7 0x000000000048cc8a in testcase_run_one (group=0x6ff270 <testgroups+112>, testcase=0x6fdc10 <bufferevent_testcases+80>) at tinytest.c:252 #8 0x000000000048d5c9 in tinytest_main (c=3, v=0x7fffffffe008, groups=0x6ff200 <testgroups>) at tinytest.c:434 #9 0x000000000047a08f in main (argc=3, argv=0x7fffffffe008) at regress_main.c:459 Found-with: regress bufferevent/bufferevent_pair_release_lock (-DEVENT__DISABLE_DEBUG_MODE=ON)

Otherwise we can trigger incorrect callback, the simplest way to trigger this is using http regression tests -- https_chunk_out, since all it do is: evhttp_send_reply_end() evbuffer_add() do_write() evhttp_write_buffer() evcon->cb = cb And indeed this is what happens: (gdb) bt #0 do_write (bev_ssl=0x738a90, atmost=16384) at bufferevent_openssl.c:717 #1 0x00000000004b69f7 in consider_writing (bev_ssl=0x738a90) at bufferevent_openssl.c:875 #2 0x00000000004b7386 in be_openssl_outbuf_cb (buf=0x7387b0, cbinfo=0x7fffffffd590, arg=0x738a90) at bufferevent_openssl.c:1147 #3 0x0000000000490100 in evbuffer_run_callbacks (buffer=0x7387b0, running_deferred=0) at buffer.c:508 #4 0x00000000004901e5 in evbuffer_invoke_callbacks_ (buffer=0x7387b0) at buffer.c:529 #5 0x0000000000493a30 in evbuffer_add (buf=0x7387b0, data_in=0x4ecfb2, datlen=5) at buffer.c:1803 #6 0x00000000004be2e3 in evhttp_send_reply_end (req=0x7371a0) at http.c:2794 #7 0x000000000045c407 in http_chunked_trickle_cb (fd=-1, events=1, arg=0x75aaf0) at regress_http.c:402 ... (gdb) p bev.writecb $4 = (bufferevent_data_cb) 0x4ba17e <evhttp_write_cb> $5 = (void *) 0x7379b0 (gdb) p (struct evhttp_connection *)bev.cbarg $6 = (struct evhttp_connection *) 0x7379b0 (gdb) p $6->cb $7 = (void (*)(struct evhttp_connection *, void *)) 0x0 And be_sock don't do like this anyway. Fixes: https_chunk_out

If you use bufferevent_socket_connect_hostname() to resolve then ipv4 answer can be returned before ipv6 scheduled and then if you will destroy bufferevent after ipv4 answer will come then ipv6 will trigger UAF: $ a.out ================================================================= ==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8 READ of size 2 at 0x60200000ef50 thread T0 #0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee) #1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739 #2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214 libevent#3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935 libevent#4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719 libevent#5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567 libevent#6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519 libevent#7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493 libevent#8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548 libevent#9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373) libevent#10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 libevent#11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806) 0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f) freed by thread T1 here: #0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2) #1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512 #2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206 libevent#3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f) libevent#4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642 libevent#5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734 libevent#6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957 libevent#7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768 libevent#8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075) libevent#9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309 Fixes: libevent#217

If you use bufferevent_socket_connect_hostname() to resolve then ipv4 answer can be returned before ipv6 scheduled and then if you will destroy bufferevent after ipv4 answer will come then ipv6 will trigger UAF: $ a.out ================================================================= ==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8 READ of size 2 at 0x60200000ef50 thread T0 #0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee) #1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739 #2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214 libevent#3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935 libevent#4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719 libevent#5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567 libevent#6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519 libevent#7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493 libevent#8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548 libevent#9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373) libevent#10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 libevent#11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806) 0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f) freed by thread T1 here: #0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2) #1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512 #2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206 libevent#3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f) libevent#4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642 libevent#5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734 libevent#6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957 libevent#7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768 libevent#8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075) libevent#9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309 Fixes: libevent#217 Closes: libevent#222 Gist: https://gist.github.com/azat/92cbb34232ac02d7972b (from libevent#217 but thread-safe)

If you use bufferevent_socket_connect_hostname() to resolve, then ipv4 answer can be returned before ipv6 scheduled and if you will destroy bufferevent after ipv4 answer will come then ipv6 will trigger UAF: $ a.out ================================================================= ==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8 READ of size 2 at 0x60200000ef50 thread T0 #0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee) #1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739 #2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214 libevent#3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935 libevent#4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719 libevent#5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567 libevent#6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519 libevent#7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493 libevent#8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548 libevent#9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373) libevent#10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 libevent#11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806) 0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f) freed by thread T1 here: #0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2) #1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512 #2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206 libevent#3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f) libevent#4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642 libevent#5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734 libevent#6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957 libevent#7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768 libevent#8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075) libevent#9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309 Fixes: libevent#217 Closes: libevent#222 Gist: https://gist.github.com/azat/92cbb34232ac02d7972b (from libevent#217 but thread-safe)

If you use bufferevent_socket_connect_hostname() to resolve, then ipv4 answer can be returned before ipv6 scheduled and if you will destroy bufferevent after ipv4 answer will come then ipv6 will trigger UAF: $ a.out ================================================================= ==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8 READ of size 2 at 0x60200000ef50 thread T0 #0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee) #1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739 #2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214 libevent#3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935 libevent#4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719 libevent#5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567 libevent#6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519 libevent#7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493 libevent#8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548 libevent#9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373) libevent#10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 libevent#11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806) 0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f) freed by thread T1 here: #0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2) #1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512 #2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206 libevent#3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f) libevent#4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642 libevent#5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734 libevent#6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957 libevent#7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768 libevent#8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075) libevent#9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309 Fixes: libevent#217 Closes: libevent#222 Closes: libevent#219 Gist: https://gist.github.com/azat/92cbb34232ac02d7972b (from libevent#217 but thread-safe)

If you use bufferevent_socket_connect_hostname() to resolve, then ipv4 answer can be returned before ipv6 scheduled and if you will destroy bufferevent after ipv4 answer will come (in a separate thread of course) then ipv6 will trigger UAF: $ a.out ================================================================= ==29733==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef50 at pc 0x0000004b7aef bp 0x7fffffffd940 sp 0x7fffffffd0f8 READ of size 2 at 0x60200000ef50 thread T0 #0 0x4b7aee in __interceptor_index (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4b7aee) #1 0x5060eb in string_num_dots /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2739 #2 0x5078df in search_request_new /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:3214 #3 0x506afd in evdns_base_resolve_ipv6 /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:2935 #4 0x50aa94 in evdns_getaddrinfo /src/oss/libevent/libevent-github/.cmake-debug/../evdns.c:4719 #5 0x51de4f in evutil_getaddrinfo_async_ /src/oss/libevent/libevent-github/.cmake-debug/../evutil.c:1567 #6 0x4fe023 in bufferevent_socket_connect_hostname /src/oss/libevent/libevent-github/.cmake-debug/../bufferevent_sock.c:519 #7 0x524f54 in evhttp_connection_connect_ /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2493 #8 0x525156 in evhttp_make_request /src/oss/libevent/libevent-github/.cmake-debug/../http.c:2548 #9 0x52d373 in main (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d373) #10 0x7ffff6849b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 #11 0x445806 in _start (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x445806) 0x60200000ef50 is located 0 bytes inside of 15-byte region [0x60200000ef50,0x60200000ef5f) freed by thread T1 here: #0 0x4cc4f2 in __interceptor_free (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x4cc4f2) #1 0x5141c1 in event_mm_free_ /src/oss/libevent/libevent-github/.cmake-debug/../event.c:3512 #2 0x522402 in evhttp_connection_free /src/oss/libevent/libevent-github/.cmake-debug/../http.c:1206 #3 0x52cc5f in connection_closer (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52cc5f) #4 0x50e80e in event_process_active_single_queue /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1642 #5 0x50ed57 in event_process_active /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1734 #6 0x50f458 in event_base_loop /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1957 #7 0x50eddf in event_base_dispatch /src/oss/libevent/libevent-github/.cmake-debug/../event.c:1768 #8 0x52d075 in event_dispatch_thread (/src/oss/libevent/libevent-github/.invest/217-evhttp-threaded/a.out+0x52d075) #9 0x7ffff74fc0a3 in start_thread /tmp/buildd/glibc-2.19/nptl/pthread_create.c:309 Fixes: #217 Closes: #222 Closes: #219 Gist: https://gist.github.com/azat/92cbb34232ac02d7972b (from #217 but thread-safe)

a backtrace of the process without this patch : * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fffb1fb7d96 libsystem_kernel.dylib`kevent + 10 frame #1: 0x0000000108ed0a58 libevent-2.2.1.dylib`kq_dispatch + 696 frame #2: 0x0000000108ec53d8 libevent-2.2.1.dylib`event_base_loop + 696 frame libevent#3: 0x0000000108e1763b regress`test_fork + 1931 frame libevent#4: 0x0000000108e5c7ad regress`run_legacy_test_fn + 45 frame libevent#5: 0x0000000108e690aa regress`testcase_run_one + 858 frame libevent#6: 0x0000000108e6954f regress`tinytest_main + 495 frame libevent#7: 0x0000000108e5c94b regress`main + 171 frame libevent#8: 0x00007fffb1e88235 libdyld.dylib`start + 1 frame libevent#9: 0x00007fffb1e88235 libdyld.dylib`start + 1 Issue: libevent#546

a backtrace of the process without this patch : * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fffb1fb7d96 libsystem_kernel.dylib`kevent + 10 frame #1: 0x0000000108ed0a58 libevent-2.2.1.dylib`kq_dispatch + 696 frame #2: 0x0000000108ec53d8 libevent-2.2.1.dylib`event_base_loop + 696 frame libevent#3: 0x0000000108e1763b regress`test_fork + 1931 frame libevent#4: 0x0000000108e5c7ad regress`run_legacy_test_fn + 45 frame libevent#5: 0x0000000108e690aa regress`testcase_run_one + 858 frame libevent#6: 0x0000000108e6954f regress`tinytest_main + 495 frame libevent#7: 0x0000000108e5c94b regress`main + 171 frame libevent#8: 0x00007fffb1e88235 libdyld.dylib`start + 1 frame libevent#9: 0x00007fffb1e88235 libdyld.dylib`start + 1 Issue: libevent#546 (cherry picked from commit a86f89d)

evutil.c:2559:1: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' #0 0x4f2be0 in EVUTIL_ISXDIGIT_ libevent/evutil.c:2559:1 #1 0x4bd689 in regname_ok libevent/http.c:4838:7 #2 0x4bc16b in parse_authority libevent/http.c:4958:9 #3 0x4bb8b5 in evhttp_uri_parse_with_flags libevent/http.c:5103:7 #4 0x4bb762 in evhttp_uri_parse libevent/http.c:5050:9 #5 0x4b8f41 in evhttp_parse_query_impl libevent/http.c:3505:9 #6 0x4b8ed7 in evhttp_parse_query libevent/http.c:3569:9 Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23291 Report: https://oss-fuzz.com/testcase-detail/5670743106125824

UBSAN reports: evbuffer/remove_buffer_with_empty3: ../buffer.c:1443:3: runtime error: null pointer passed as argument 2, which is declared to never be null #0 0x7ffff6cd0410 in evbuffer_pullup ../buffer.c:1443 #1 0x5555556d68b9 in test_evbuffer_remove_buffer_with_empty3 ../test/regress_buffer.c:408 #2 0x5555557b95ee in testcase_run_bare_ ../test/tinytest.c:173 #3 0x5555557ba048 in testcase_run_one ../test/tinytest.c:333 #4 0x5555557bc0f8 in tinytest_main ../test/tinytest.c:527 #5 0x555555787702 in main ../test/regress_main.c:528 #6 0x7ffff606c001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) #7 0x55555569436d in _start (/src/le/libevent/.cmake-debug/bin/regress+0x14036d)

…sponse() In case of OPT pseudo-RR `class` field is treated as a requestor's UDP payload size, and class will have 512 (DNS_MAX_UDP_SIZE), and data is NULL: (gdb) p *item $4 = { next = 0x0, name = 0x602000000130 "", type = 41, class = 512, ttl = 0, is_name = 0 '\000', datalen = 0, data = 0x0 } And UBSAN will reports: ../evdns.c:2493:5: runtime error: null pointer passed as argument 2, which is declared to never be null #0 0x7ffff70b65bb in evdns_server_request_format_response ../evdns.c:2493 #1 0x7ffff70b706b in evdns_server_request_respond ../evdns.c:2529 #2 0x5555557975ab in regress_dns_server_cb ../test/regress_testutils.c:263 #3 0x7ffff70a8489 in request_parse ../evdns.c:1576 #4 0x7ffff70aa445 in server_udp_port_read ../evdns.c:1726 #5 0x7ffff70ac5cc in server_port_ready_callback ../evdns.c:1849 #6 0x7ffff6d3054c in event_persist_closure ../event.c:1645 #7 0x7ffff6d311cd in event_process_active_single_queue ../event.c:1704 #8 0x7ffff6d33258 in event_process_active ../event.c:1805 #9 0x7ffff6d361b5 in event_base_loop ../event.c:2047 #10 0x7ffff6d334ac in event_base_dispatch ../event.c:1839 #11 0x555555739df2 in test_edns ../test/regress_dns.c:2639 #12 0x5555557b9e96 in testcase_run_bare_ ../test/tinytest.c:173 #13 0x5555557ba8f0 in testcase_run_one ../test/tinytest.c:333 #14 0x5555557bc9a0 in tinytest_main ../test/tinytest.c:527 #15 0x555555787faa in main ../test/regress_main.c:528 #16 0x7ffff606c001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) #17 0x55555569436d in _start (/src/le/libevent/.cmake-debug/bin/regress+0x14036d)

evutil.c:2559:1: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' #0 0x4f2be0 in EVUTIL_ISXDIGIT_ libevent/evutil.c:2559:1 #1 0x4bd689 in regname_ok libevent/http.c:4838:7 #2 0x4bc16b in parse_authority libevent/http.c:4958:9 libevent#3 0x4bb8b5 in evhttp_uri_parse_with_flags libevent/http.c:5103:7 libevent#4 0x4bb762 in evhttp_uri_parse libevent/http.c:5050:9 libevent#5 0x4b8f41 in evhttp_parse_query_impl libevent/http.c:3505:9 libevent#6 0x4b8ed7 in evhttp_parse_query libevent/http.c:3569:9 Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23291 Report: https://oss-fuzz.com/testcase-detail/5670743106125824 (cherry picked from commit 37dbb35)

UBSAN reports: evbuffer/remove_buffer_with_empty3: ../buffer.c:1443:3: runtime error: null pointer passed as argument 2, which is declared to never be null #0 0x7ffff6cd0410 in evbuffer_pullup ../buffer.c:1443 #1 0x5555556d68b9 in test_evbuffer_remove_buffer_with_empty3 ../test/regress_buffer.c:408 #2 0x5555557b95ee in testcase_run_bare_ ../test/tinytest.c:173 libevent#3 0x5555557ba048 in testcase_run_one ../test/tinytest.c:333 libevent#4 0x5555557bc0f8 in tinytest_main ../test/tinytest.c:527 libevent#5 0x555555787702 in main ../test/regress_main.c:528 libevent#6 0x7ffff606c001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) libevent#7 0x55555569436d in _start (/src/le/libevent/.cmake-debug/bin/regress+0x14036d) (cherry picked from commit a0c642a)

artemg mentioned this issue Mar 27, 2012

Assertion fail in evdns #3

Closed

nmathewson mentioned this issue Aug 23, 2012

Setting a bufferevent timeout to NULL does not work #16

Closed

nmathewson closed this as completed Nov 16, 2012

tunwei mentioned this issue Apr 9, 2013

SIG_ABRT observe #52

Closed

huster-zhangpeng mentioned this issue Aug 19, 2015

libevent-2.1.5 beta http.c:691: Assertion req != NULL failed in evhttp_connection_fail_ #272

Closed

varunnith mentioned this issue Dec 10, 2015

segfault when trying to call event_dispatch from a pthread #295

Closed

wangxiaoying mentioned this issue Mar 4, 2016

bufferevent: connect/resolv cancellation #333

Closed

BrentHuang mentioned this issue Jun 13, 2016

my http server use 100% cpu #363

Closed

vyan mentioned this issue Jun 28, 2016

libevent coredump in calloc #371

Closed

zourva mentioned this issue Feb 22, 2017

event_queue_remove_active: not on queue 8 #469

Closed

lzy-lyf mentioned this issue May 23, 2017

(Bug?)Deadlock happend #512

Closed

lindianyin mentioned this issue Sep 12, 2017

./bin/https-client -url https://www.taobao.com/ may be crash #557

Closed

vnsavage mentioned this issue Sep 26, 2017

Segfaults when bufferevent_new() is called (PECL) #565

Closed

eric2ya mentioned this issue Jan 16, 2018

event_base_loop event_queue_remove_timeout "Segmentation fault" #586

Closed

frokaikan mentioned this issue Dec 1, 2018

segv on regress #727

Closed

hdatma mentioned this issue Jan 25, 2019

regress main/fork hangs #747

Closed

jurgenyang mentioned this issue Feb 19, 2019

libevent coredump in event_active_nolock_ #767

Closed

jacksu mentioned this issue Mar 15, 2019

Someone has the same core information?? #790

Closed

nickli814 mentioned this issue Mar 20, 2019

bufferevent core dumped after calling bufferevent_free() function #791

Closed

msrinirao mentioned this issue Apr 10, 2019

Libevent crashed on call to evhttp_clear_headers() #797

Closed

philberty mentioned this issue Jul 9, 2019

EXC_BAD_ACCESS mac event add #852

Closed

oliver-jinfeng mentioned this issue Jul 12, 2019

libevent 2.0.22-stable: a coredump in _evbuffer_decref_and_unlock #283

Closed

TomerHeber mentioned this issue Jan 21, 2020

ssl bufferevent with underlying bufferevent - infinite loop/stack overflow. #952

Open

This was referenced Mar 18, 2020

How to solve curl: (35) Unknown SSL protocol error in connection to x.x.x.x #971

Closed

what's the reason of this backtrace? #980

Closed

okayabc mentioned this issue Mar 30, 2020

When i do pressure test using jmeter, libevent crash after one hour later, what’s the possible reason？ #991

Closed

frokaikan mentioned this issue Jun 12, 2020

format-string vulnerability? #1035

Closed

cnliuhb mentioned this issue Jul 21, 2020

Coredump when using sample/le-proxy.c #1057

Closed

cnliuhb mentioned this issue Jul 30, 2020

Coredump when using bufferevent #1065

Closed

merkaG mentioned this issue Jan 26, 2022

crash in TAILQ_REMOVE #1248

Closed

NKTelnet mentioned this issue Jul 19, 2022

libevent 2.1.12 infinite loop in transaction_id_pick #1310

Closed

saivikas-dharma mentioned this issue Jan 19, 2023

Multi Threaded http server binding to same port #1396

Open

This was referenced Apr 16, 2023

A memory corruption issue on a HTTPs server using libevent (with rate limit enabled) #1439

Closed

buffer.c:2247: Assertion chain failed in evbuffer_read_setup_vecs_ #1440

Closed

Dabiaoge6 mentioned this issue Jul 11, 2023

The code has a null pointer problem in release-2.1.12-stable #1489

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Write a test for event_add(ev,NULL) on an event with an existing timeout #5

Write a test for event_add(ev,NULL) on an event with an existing timeout #5

nmathewson commented Mar 27, 2012

nmathewson commented Aug 23, 2012

nmathewson commented Nov 16, 2012

Write a test for event_add(ev,NULL) on an event with an existing timeout #5

Write a test for event_add(ev,NULL) on an event with an existing timeout #5

Comments

nmathewson commented Mar 27, 2012

nmathewson commented Aug 23, 2012

nmathewson commented Nov 16, 2012