Re: PaX killing conntrackd (strange "execution attempt")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Wolfram Schlich <lists@xxxxxxxxxxxxxxxxxxx> [2008-11-13 14:27]:
> Here's the answer from the PaX team, for those who might be interested:
> * pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> [2008-11-13 14:18]:
> > [...]
> > this is a null function pointer dereference problem on the surface and you'll have to
> > debug it to get more info. i wonder why nothing shows up in the stack dump however,
> > maybe there's more corruption here behind the scenes. once you get the coredumps (and
> > i hope you have debug info saved away ;) we can get a backtrace and other things. also
> > disable randomization in /proc/sys/... so that results are comparable. best would be
> > to find a way to directly trigger this crash, then you could have a live gdb session
> > instead of coredump analysis.
> 
> I'll take care of these suggestions now and let you know
> about any news.

I've now recompiled conntrack-tools using these CFLAGS:

	-march=nocona -O0 -ggdb -DDEBUG

Also, the binaries were not stripped anymore:

	/usr/sbin/conntrackd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped

(I forgot to mention I'm on a 64bit kernel + userland).

I'm now stressing the firewalls with packets.
-- 
Regards,
Wolfram Schlich <wschlich@xxxxxxxxxx>
Gentoo Linux * http://dev.gentoo.org/~wschlich/
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux