[Openswan Users] Pluto segfault on openswan-2.6.23

[Paul Wouters]

On Tue, 6 Oct 2009, Giovani Moda wrote:

>> Yes, you can attach to pluto as well, though I can't see why it would
>> crash but not core dump if kill -6 works.
>
> Could it be because it's not the "main" process that gets a segfault?
> When I search for pluto pids, I get three processes running:

> 1) /bin/sh /usr/local/lib/ipsec/_plutorun 
> 2) /bin/sh /usr/local/lib/ipsec/_plutorun
> 3) /usr/local/libexec/ipsec/pluto

the first two are scripts, the 3rd is the actual pluto process.

> The one crashing is always number 3.

then it should core dump wtiht a dumpdir= set if the OS allows it. I
really think your OS is preventing the core dump somehow.

> I can't get no backtrace at all. I've installed debug libraries for
> glibc, ncurses, gmp, gcc and kernel, so gdb could read all necessary
> symbols, attached to the pid of processes 3 (as stated above), crashed,
> and got " No stack." on "bt full". Here is the output:
>
> [root at inet pluto]# gdb -p 12661

Is this the pluto dir in hte OBJ* directory where the pluto source+ binary
files live?

> I don't know if it helps, but here is the Oops:
>
> BUG: unable to handle kernel NULL pointer dereference at 00000000
> IP: [<f917b32d>] :ipsec:aes_32+0x3/0x496

That's a kernel bug, so tracing the userland process won't help. As
a workaround, you can try esp=3des and ike=3des-sha1 to avoid the aes
code.

> Pid: 11691, comm: pluto Not tainted (2.6.27.35-79.2.56.fc9_mr.i686 #1)

I have not tested 2.6.27 yet with KLIPS. There is probably a (undocumented)
kernel API change that requires some code in ipsec_kversion.h

Paul