Project

General

Profile

Bug #1545

charon-systemd sigsev when loading configuration via vici at second attempt

Added by Noel Kuntze about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
libstrongswan
Target version:
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

Is duplicate of Bug #1488: charon crashes when running 'swanctl --load-conns'Closed28.05.2016

History

#1 Updated by Tobias Brunner about 4 years ago

  • Is duplicate of Bug #1488: charon crashes when running 'swanctl --load-conns' added

#2 Updated by Tobias Brunner about 4 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

Also available in: Atom PDF