Bug #1545
charon-systemd sigsev when loading configuration via vici at second attempt
Start date:
01.07.2016
Due date:
Estimated time:
Affected version:
5.4.0
Resolution:
Duplicate
Description
Hello,
I encountered a crash of charon-systemd when trying to load the configuration via vici socket with swanctl.
But it only crashes when I load the configuration two times.
Yes, the configuration is deliberately incomplete. That is how it was loaded.
I think it is one of the few instances where a char * is accidently not initialised when trying to operate on it later.
strongswan-swanctl.service:
[Unit] Description=strongSwan IPsec IKEv1/IKEv2 daemon using swanctl After=network.target [Service] Type=notify ExecStart=/usr/bin/charon-systemd ExecStartPost=/usr/bin/swanctl --load-all --noprompt ExecReload=/usr/bin/swanctl --reload [Install] WantedBy=multi-user.target
swanctl.conf:
connections { foo { local { } remote { } children { bar { } } } vms { version = 2 fragmentation = yes dpd_delay = 2s dpd_timeout = 16s proposals = aes192gcm12-prfaesxcbc-ecp521 local { auth = pubkey pubkeys = } remote { auth = pubkey pubkeys = } children { vms-ah { ah_proposals = aesxcbc-ecp521 mode = transport start_action = none } } } }
Stack trace acquired with gdb:
#0 0x00007ffff73bc60a in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6 [38/434] No symbol table info available. #1 0x00007ffff78fe654 in streq (y=<optimized out>, x=<optimized out>) at ../../src/libstrongswan/utils/utils/string.h:30 No locals. #2 equals (this=0x7fff10001df0, other_pub=0x7fff84001df0) at config/child_cfg.c:582 other = 0x7fff84001df0 other_pub = 0x7fff84001df0 this = 0x7fff10001df0 other = 0x7fff84001df0 #3 0x00007ffff78fff03 in replace_child_cfgs (this=0x7fff10002a70, other_pub=<optimized out>) at config/peer_cfg.c:279 other = <optimized out> removed = 0x7fff840011a0 added = 0x7fff84001270 mine = 0x7fff84001100 others = 0x7fff84002600 my_cfg = 0x7fff10001df0 other_cfg = 0x7fff84001df0 enumerator = <optimized out> found = <optimized out> #4 0x00007ffff13e0b12 in replace_children (to=0x7fff10002a70, from=0x7fff84002a70, this=0x6d0880) at vici_config.c:1900 enumerator = <optimized out> child = 0xe0 added = false #5 merge_config (peer_cfg=0x7fff84002a70, this=0x6d0880) at vici_config.c:1935 enumerator = 0x7fff84000980 current = 0x7fff10002a70 ike_cfg = <optimized out> merged = false #6 _cb_config_sn (request=request@entry=0x7ffeba7e3b50, message=message@entry=0x7fff84000ce0, ctx=ctx@entry=0x7ffeba7e3af0, name=<optimized out>) at vici_config.c:2133 peer = {request = 0x7ffeba7e3b50, version = 0, aggressive = false, encap = false, mobike = true, send_certreq = true, pull = true, send_cert = CERT_SEND_IF_ASKED, dpd_delay = 0, dpd_timeout = 0, fragmentation = FRAGMENTATION_NO, unique = UNIQUE_NO, keyingtries = 1, local_port = 500, remote_port = 500, local_addrs = 0x7fff840026a0 "\360\035", remote_addrs = 0x7fff84001dd0 "", local = 0x7fff84001070, remote = 0x7fff84001140, proposals = 0x7fff84001210, children = 0x7fff840012e0, vips = 0x7fff840013b0, pools = 0x0, reauth_time = 0, rekey_time = 14400, over_time = 1440, rand_time = 1440} enumerator = <optimized out> peer_cfg = 0x7fff84002a70 ike_cfg = 0x7fff84001790 child_cfg = 0x7fff84001df0 auth = 0x7fff84001520 proposal = 0x7fff840016c0 host = 0x400000000 str = 0xc <error: Cannot access memory at address 0xc> #7 0x00007ffff13d5ca3 in parse (this=0x7fff84000ce0, ctx=0x7ffeba7e3af0, section=0x7ffff13dfde0 <_cb_config_sn>, kv=0x0, li=0x0, user=0x7ffeba7e3b50) at vici_message.c:532 root = {level = 0, e = 0x7fff84000e80} name = 0x7fff84000cc0 "foo" list = 0x0 type = VICI_SECTION_START value = {ptr = 0x7fff840009bb "\001\003foo\001\005local\002\001\006remote\002\001\bchildren\001\003bar\002\002\002", len = 140737341190612} base = 0 ok = <optimized out> #8 0x00007ffff13df2eb in _cb_load_conn (this=<optimized out>, name=<optimized out>, id=<optimized out>, message=<optimized out>) at vici_config.c:2145 request = {this = 0x6d0880, reply = 0x0} #9 0x00007ffff13d7876 in process_request (this=this@entry=0x6ceb40, name=name@entry=0x7ffeba7e3bf0 "load-conn", id=id@entry=2, data=...) at vici_dispatcher.c:289 response = 0x0 release = 0x7fff84000c00 cmd = 0x6d0a90 #10 0x00007ffff13d7c11 in _cb_inbound (this=0x6ceb40, id=2, data=...) at vici_dispatcher.c:346 reader = 0x7fff84000b20 chunk = {ptr = 0x7fff840009b2 "load-conn\001\003foo\001\005local\002\001\006remote\002\001\bchildren\001\003bar\002\002\002", len = 9} type = 0 '\000' name = "load-conn\000=\361\377\177", '\000' <repeats 34 times>, "(", '\000' <repeats 79 times>, "\030\000\000\000\000\000\000\000 \000\000\204\377\177\000\000(\000\000\000\000\000\00 0\000\360\354l\000\000\000\000\000\002\000\000\000\000\000\000\000+\000\000\000\000\000\000\000\200\206`", '\000' <repeats 13 times>, "\370<~\272\376\177\000\000"... #11 0x00007ffff13d4a8e in _cb_process_queue (sel=0x7fff84000a30) at vici_socket.c:508 entry = 0x7ffed8000b70 chunk = {ptr = 0x7fff840009b0 "", len = 51} found = <optimized out> id = 2 #12 0x00007ffff7ba6a8e in execute (this=<optimized out>) at processing/jobs/callback_job.c:77 No locals. #13 0x00007ffff7ba7330 in process_job (worker=0x6e5300, this=0x608680) at processing/processor.c:235 to_destroy = 0x0 requeue = <optimized out> #14 process_jobs (worker=0x6e5300) at processing/processor.c:321 this = 0x608680 #15 0x00007ffff7bb7da7 in thread_main (this=0x6e5330) at threading/thread.c:322 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {104, -6929040428955402731, 0, 140737488345647, 7230256, 140737354125312, 6929472530575719957, 6929057441407893013}, __mask_was_saved = 0}}, __pad = {0x7ffeba7e3eb0, 0x0, 0x0, 0x0}} __cancel_routine = 0x7ffff7bb7eb0 <thread_cleanup> __cancel_arg = 0x6e5330 __not_first_call = <optimized out> res = <optimized out> #16 0x00007ffff76d7484 in start_thread () from /usr/lib/libpthread.so.0 No symbol table info available. #17 0x00007ffff74166dd in clone () from /usr/lib/libc.so.6 No symbol table info available.
Related issues
History
#1 Updated by Tobias Brunner about 9 years ago
- Is duplicate of Bug #1488: charon crashes when running 'swanctl --load-conns' added
#2 Updated by Tobias Brunner about 9 years ago
- Tracker changed from Issue to Bug
- Category set to libstrongswan
- Status changed from New to Closed
- Assignee set to Tobias Brunner
- Target version set to 5.5.0
- Resolution set to Duplicate