#82 racoon-0.8.0 segfaults if privsep is used



I have a following setup: racoon from ipsec-tools-0.8.0, privsep is enabled, on *any* new incoming
connection (INITIAL-CONTACT) racoon segfaults:

May 27 16:44:13 [racoon] INFO: respond new phase 1 negotiation:[500]<=>[500]_
May 27 16:44:13 [racoon] INFO: begin Identity Protection mode._
May 27 16:44:13 [racoon] INFO: received Vendor ID: DPD_
May 27 16:44:13 [racoon] WARNING: CERT validation disabled by configuration_
May 27 16:44:13 [racoon] INFO: ISAKMP-SA established[500]-[500] spi:e018f61cc1ff7c11:894fe14faf0969f2_
May 27 16:44:13 [racoon] [] INFO: received INITIAL-CONTACT_
May 27 16:44:13 [racoon] ERROR: privsep_socket: unauthorized domain (15)_
May 27 16:44:13 [racoon] INFO: racoon privileged process 29659 terminated_
May 27 16:44:13 [kernel] racoon[29686]: segfault at 10 ip 0000000000423ab6 sp 00007fffefd5a010 error 4 in racoon[400000+94000]

Config file is attached, even without chroot this crash is reproducible, with privsep completely disabled
racoon works normally.

My distribution is Gentoo, running 3.2.14 kernel. I use only AH tunelling for this connection.
Older racoon from ipsec-tools-0.7.3 works fine under the same conditions.


  • Andrew

    Andrew - 2012-05-27


  • Andrew

    Andrew - 2012-07-19

    Steps to reproduce:

    0) You need either third host C with non-ipsec access to A and B hosts or direct physical/kvm/ilo access to both A and B host.
    1) Stop racoon on both sides (A and B) of ipsec connection.
    2) rc-config start racoon on A.
    3) rc-config start racoon on B.
    4) on B: ping A
    5) Segfault on A!

    I recompiled racoon with CFLAGS="-ggdb" and managed to get gdb backtrace on host A:

    #0 0x000000000042ee8a in rec_fd (s=11) at privsep.c:1574
    #1 0x000000000042df41 in privsep_socket (domain=15, type=3, protocol=2) at privsep.c:1144
    #2 0x000000000042fa96 in pfkey_dump_sadb (satype=0) at pfkey.c:312
    #3 0x0000000000427d63 in isakmp_info_recv_initialcontact (iph1=0x19f4f20, protectedph2=0x0) at isakmp_inf.c:1305
    #4 0x0000000000425fbe in isakmp_info_recv_n (iph1=0x19f4f20, notify=0x19ebc40, msgid=2587936451, encrypted=1) at isakmp_inf.c:411
    #5 0x0000000000425af2 in isakmp_info_recv (iph1=0x19f4f20, msg0=0x19f54c0) at isakmp_inf.c:294
    #6 0x000000000040980c in isakmp_main (msg=0x19f54c0, remote=0x7fff56e3dc90, local=0x7fff56e3dc10) at isakmp.c:652
    #7 0x0000000000408dbd in isakmp_handler (ctx=0x0, so_isakmp=8) at isakmp.c:377
    #8 0x0000000000408021 in session () at session.c:325
    #9 0x000000000040757b in main (ac=4, av=0x7fff56e3ef18) at main.c:345

  • Andrew

    Andrew - 2012-07-19

    This bug happens only in the tunnel ipsec mode and can't be reproduced for the transport mode. The following setkey is an example required to reproduce a crash on the host A:

    #!/usr/sbin/setkey -f

    spdadd B A any -P in ipsec
    spdadd A B any -P out ipsec

  • Andrew

    Andrew - 2012-07-19

    Ignore my previous post: racoon was tested with privsep disabled. With privsep enabled racoon crashes regardles to mode set.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks