Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pluto segfaults in IKEv1 phase 2 setup #424

Open
edgmnt-psft opened this issue Jan 9, 2020 · 2 comments
Open

pluto segfaults in IKEv1 phase 2 setup #424

edgmnt-psft opened this issue Jan 9, 2020 · 2 comments

Comments

@edgmnt-psft
Copy link

edgmnt-psft commented Jan 9, 2020

I'm using OpenSWAN 2.6.51.5 on an ARM-based board running Linux 3.7.5 (KLIPS) to connect to an IKEv1 peer. It looks like pluto always segfaults when setting up phase 2, here's what gdb catches:

(gdb) bt
#0  addrtypeof (src=src@entry=0x1b8)
    at openswan-2.6.51.5/lib/libopenswan/addrtypeof.c:25
#1  0xb6ec3a6c in eroute_connection (st=st@entry=0x0, sr=sr@entry=0xbe8903f8, 
    spi=spi@entry=17825792, proto=4, esatype=ET_IPIP, proto_info=0xbe89020c, 
    proto_info@entry=0xbe890204, op=op@entry=1, opname=opname@entry=0xb6f248b8 "add", 
    policy_label=policy_label@entry=0x0)
    at openswan-2.6.51.5/programs/pluto/kernel.c:1189
#2  0xb6ecb45c in pfkey_sag_eroute (st=<optimized out>, sr=0xbe8903f8, op=1, 
    opname=0xb6f248b8 "add")
    at openswan-2.6.51.5/programs/pluto/kernel_pfkey.c:1431
#3  0xb6ec073c in sag_eroute (st=st@entry=0xb6f731a0, sr=sr@entry=0xbe8903f8, 
    op=op@entry=ERO_ADD, opname=opname@entry=0xb6f248b8 "add")
    at openswan-2.6.51.5/programs/pluto/kernel.c:801
#4  0xb6ec4ac0 in route_and_eroute (c=0xb6f6fb30, sr=sr@entry=0xbe8903f8, 
    orig_sr=orig_sr@entry=0xb6f6fb90, st=st@entry=0xb6f731a0)
    at openswan-2.6.51.5/programs/pluto/kernel.c:2685
#5  0xb6ec4fdc in install_ipsec_sa (parent_st=<optimized out>, st=st@entry=0xb6f731a0, 
    inbound_also=inbound_also@entry=1)
    at openswan-2.6.51.5/programs/pluto/kernel.c:2983
#6  0xb6eb0c10 in quick_inR1_outI2_cryptotail (dh=dh@entry=0xb6f72fd0, 
    r=r@entry=0xbe890768)
    at openswan-2.6.51.5/programs/pluto/ikev1_quick.c:2608
#7  0xb6eb0ec4 in quick_inR1_outI2_continue (pcrc=0xb6f72fd0, r=0xbe890768, 
    ugh=<optimized out>)
    at openswan-2.6.51.5/programs/pluto/ikev1_qu--Type <RET> for more, q to quit, c to continue without paging--
ick.c:2441
#8  0xb6ed21b4 in handle_helper_comm (w=w@entry=0xb6f6fab0)
    at openswan-2.6.51.5/programs/pluto/pluto_crypt.c:826
#9  0xb6ed2e5c in pluto_crypto_helper_ready (readfds=0xbe891dc8, readfds@entry=0x100)
    at openswan-2.6.51.5/programs/pluto/pluto_crypt.c:1100
#10 0xb6ea17b4 in call_server ()
    at openswan-2.6.51.5/programs/pluto/server.c:799
#11 0xb6e8f620 in main (argc=-1225416752, argv=0x0)
    at openswan-2.6.51.5/programs/pluto/plutomain.c:1134

According to pfkey_sag_route(), eroute_connection() is always called with NULL_STATE in the first parameter, so I wonder if this ever works. What do you think?

@edgmnt-psft
Copy link
Author

Can someone take a look at this? It's making IKEv1 unusable for me.

@letoams
Copy link
Contributor

letoams commented May 11, 2020

looks like eroute_connection() is passed an NULL state. Looks like something got deleted, then the crypto helper came back and it tried to continue to use a now-deleted state.

since this bug has not been worked on in 5 months, perhaps you want to try libreswan, which is a drop in replacement (forked in 2011 from openswan). Unlike openswan, it is actively developed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants