summaryrefslogtreecommitdiffstats
path: root/src/vlibmemory/memory_client.c
diff options
context:
space:
mode:
authorAndrew Yourtchenko <ayourtch@gmail.com>2021-03-11 12:54:11 +0000
committerFlorin Coras <florin.coras@gmail.com>2021-03-19 18:43:30 +0000
commit162b70d50aaf5daa744417818c01cae573580f6f (patch)
tree04d2b81002ae2e83db30b3a38a6bb2e73b8dd9ee /src/vlibmemory/memory_client.c
parent415cd67c296038133f7896cd1eaf64d9d131d90d (diff)
api: Avoid the usage of the freed registration by the API calls
This issue happens if: - the API client connects via Unix socket - the client issues the *_dump API call and immediately disconnects What happens after is that the API handler keeps sending the *_details messages, however at some point the write fails, and the socket is deleted. The attempt of a use of the registration pointer results in interpreting the socket as a shared memory socket. This results in a crash, because the data in this structure then does not make sense, like the below: | |Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. |__GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:67 |67 ../nptl/pthread_mutex_lock.c: No such file or directory. |(gdb) bt |#0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:67 |#1 0x00007ffff500f957 in svm_queue_lock (q=0x0) at /home/ubuntu/vpp/src/svm/queue.c:101 |#2 svm_queue_add (q=0x0, elem=0x7fffa76c2de0 "\210\365\006\060\001", nowait=0) at /home/ubuntu/vpp/src/svm/queue.c:274 |#3 0x00007ffff6e131e3 in vl_api_send_msg (rp=<optimized out>, elem=<optimized out>) at /home/ubuntu/vpp/src/vlibmemory/api.h:43 |#4 send_sw_interface_details (am=<optimized out>, rp=<optimized out>, swif=0x7fffb957a0bc, interface_name=<optimized out>, context=<optimized out>) | at /home/ubuntu/vpp/src/vnet/interface_api.c:353 |#5 0x00007ffff6e0edeb in vl_api_sw_interface_dump_t_handler (mp=<optimized out>) at /home/ubuntu/vpp/src/vnet/interface_api.c:412 |#6 0x00007ffff7daeb48 in msg_handler_internal (am=<optimized out>, the_msg=0x7fffb839a5e0, trace_it=<optimized out>, do_it=1, free_it=0) | at /home/ubuntu/vpp/src/vlibapi/api_shared.c:501 |#7 vl_msg_api_socket_handler (the_msg=0x7fffb839a5e0) at /home/ubuntu/vpp/src/vlibapi/api_shared.c:790 |#8 0x00007ffff7d7c608 in vl_socket_process_api_msg (rp=<optimized out>, input_v=0x7fffa76c2de0 "\210\365\006\060\001") at /home/ubuntu/vpp/src/vlibmemory/socket_api.c:212 |#9 0x00007ffff7d89ff1 in vl_api_clnt_process (vm=<optimized out>, node=<optimized out>, f=<optimized out>) at /home/ubuntu/vpp/src/vlibmemory/vlib_api.c:405 |#10 0x00007ffff53bf9a7 in vlib_process_bootstrap (_a=<optimized out>) at /home/ubuntu/vpp/src/vlib/main.c:1490 |#11 0x00007ffff4da0b2c in clib_calljmp () from /home/ayourtch/vpp/build-root/install-vpp-native/vpp/lib/libvppinfra.so.21.06 |#12 0x00007fffa99a4d90 in ?? () |#13 0x00007ffff53b6cb2 in vlib_process_startup (vm=0x7ffff56a9880 <vlib_global_main>, p=0x7fffb5d41380, f=0x0) at /home/ubuntu/vpp/src/vlib/main.c:1515 |#14 dispatch_process (vm=0x7ffff56a9880 <vlib_global_main>, p=0x7fffb5d41380, f=0x0, last_time_stamp=<optimized out>) at /home/ubuntu/vpp/src/vlib/main.c:1571 |#15 0x0000000000000000 in ?? () |(gdb) frame 3 |#3 0x00007ffff6e131e3 in vl_api_send_msg (rp=<optimized out>, elem=<optimized out>) at /home/ubuntu/vpp/src/vlibmemory/api.h:43 |43 vl_msg_api_send_shmem (rp->vl_input_queue, (u8 *) & elem); |(gdb) l |38 { |39 vl_socket_api_send (rp, elem); |40 } |41 else |42 { |43 vl_msg_api_send_shmem (rp->vl_input_queue, (u8 *) & elem); |44 } |45 } |46 |47 always_inline int |(gdb) | The approach in this change is to avoid the closing operations "here and now", but instead mark the the registration as a zombie and place a forced RPC towards a callback that does the actual cleanup work. Forced RPC is handled via the API processing loop with barrier sync, so we are guaranteed not to have any API processing in-process. Type: fix Change-Id: I1972d42da620bdb4fd773c83262863c2781d9005 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Diffstat (limited to 'src/vlibmemory/memory_client.c')
0 files changed, 0 insertions, 0 deletions