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

[Wolfram Schlich <lists@wolfram.schlich.org>]

* Pablo Neira Ayuso <pablo@netfilter.org> [2008-11-13 15:43]:
> Wolfram Schlich wrote:
> > Here's the answer from the PaX team, for those who might be interested:
> > 
> > * pageexec@freemail.hu <pageexec@freemail.hu> [2008-11-13 14:18]:
> >> On 13 Nov 2008 at 11:03, Wolfram Schlich wrote:
> >>> --8<--
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.notice; kernel: ip4t_FW DENY_IN: IN=eth1 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=XX.XXX.XX.XX DST=XX.XX.XXX.X LEN=48 TO
> >>> S=0x00 PREC=0x00 TTL=118 ID=23801 DF PROTO=TCP SPT=2608 DPT=21 WINDOW=65535 RES=0x00 SYN URGP=0
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.err; kernel: PAX: execution attempt in: <NULL>, 00000000-00000000 00000000
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.err; kernel: PAX: terminating task: /usr/sbin/conntrackd(conntrackd):6562, uid/euid: 0/0, PC: 0000000000000000, SP: 0000797077f7ea48
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.err; kernel: PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.err; kernel: PAX: bytes at SP-8:
> >>> 2008-11-13 07:38:34 +01:00; hafw2; kern.alert; kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/sbin/conntrackd[conntrackd:
> >>> 6562] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
> >>> --8<--
> >>>
> >>> The log messages look somewhat strange, especially the 'NULL',
> >>> '000..' and '??' parts :) I've always only seen such messages
> >>> with a more meaningful content so far, thus I'm a bit confused.
> >>>
> >>> What might be the reason for that?
> >> 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.
> 
> Thank you. BTW, what version of conntrackd is triggering this problem?
> Is it latest 0.9.8?

Yep, as you can see from my initial mail :)
-- 
Regards,
Wolfram Schlich <wschlich@gentoo.org>
Gentoo Linux * http://dev.gentoo.org/~wschlich/