[Oisf-devel] Segmentation fault on the latest Suricata beta

[Duarte Silva]

Hi Victor,

I have come to a conclusion about this. The fact that Suricata is compiled 
with stack protection and position independent code, doesn't seem to have 
anything to do with the issue in hand.

Actually, that specific segmentation fault did not happened again (another one 
did, I didn't compare back traces correctly :/).

Anyway, the new segmentation fault still happens on master, at least, up to 
commit 3967bd5517e7ab57fd82d7ce9b70dac16057b8f7. Issue opened at [1].

Cheers,
Duarte Silva

[1] https://redmine.openinfosecfoundation.org/issues/1101

On Thursday 23 January 2014 15:30:05 Duarte Silva wrote:
> On Friday 20 December 2013 16:53:43 Victor Julien wrote:
> > On 12/20/2013 04:50 PM, Duarte Silva wrote:
> > > On Friday 20 December 2013 16:30:33 Victor Julien wrote:
> > >> On 12/20/2013 04:23 PM, Duarte Silva wrote:
> > >>> On Thursday 19 December 2013 14:40:33 Duarte Silva wrote:
> > >>>> On Thursday 19 December 2013 15:05:17 Victor Julien wrote:
> > >>>>> On 12/19/2013 02:42 PM, Duarte Silva wrote:
> > >>>>>> Hi guys,
> > >>>>>> 
> > >>>>>> just a heads up, there is a segmentation fault when using the HTTP
> > >>>>>> custom
> > >>>>>> log (while printing the host name) on the latest 2.0 beta.
> > >>>>>> 
> > >>>>>> I have looked at the code and will create a pull request on GitHub
> > >>>>>> with
> > >>>>>> a
> > >>>>>> possible fix. More info can be found at [1].
> > >>>>> 
> > >>>>> Thanks Duarte, looking forward to the patch.
> > >>>> 
> > >>>> It seems to be a regression. I have created the pull request [1]
> > >>>> (already
> > >>>> tested it and no segmentation fault has occurred).
> > >>>> 
> > >>>> [2] https://github.com/inliniac/suricata/pull/734
> > >>>> 
> > >>>>>> Another thing, the issue [2] can be closed.
> > >>> 
> > >>> Just for the record, the issue reported on [2] happened again. I think
> > >>> the
> > >>> reason is related with the fact that, while testing the patch for [1],
> > >>> I
> > >>> was compiling Suricata with all stack protections enabled. After
> > >>> disabling that, Suricata hasn't crashed when a signature matches (it
> > >>> has
> > >>> been running for 22 hours and matched signatures 21 times) .
> > >>> 
> > >>> Follows the patch I used to enable stack protections:
> > >>> 
> > >>> diff --git a/configure.ac b/configure.ac
> > >>> index 4b394c6..e0c9ec5 100644
> > >>> --- a/configure.ac
> > >>> +++ b/configure.ac
> > >>> @@ -246,10 +246,10 @@
> > >>> 
> > >>>      AS_IF([test "x$enable_gccprotect" = "xyes"], [
> > >>>      
> > >>>          #buffer overflow protection
> > >>> 
> > >>> -        AC_MSG_CHECKING(for -fstack-protector)
> > >>> +        AC_MSG_CHECKING(for -fstack-protector-all)
> > >>> 
> > >>>          TMPCFLAGS="${CFLAGS}"
> > >>> 
> > >>> -        CFLAGS="${CFLAGS} -fstack-protector"
> > >>> -        AC_TRY_LINK(,,SECCFLAGS="${SECCFLAGS} -fstack-protector"
> > >>> +        CFLAGS="${CFLAGS} -fstack-protector-all"
> > >>> +        AC_TRY_LINK(,,SECCFLAGS="${SECCFLAGS} -fstack-protector-all"
> > >>> 
> > >>>          AC_MSG_RESULT(yes),
> > >>>          AC_MSG_RESULT(no))
> > >>>          CFLAGS="${TMPCFLAGS}"
> > >>> 
> > >>> Hope it helps in future problems, cheers,
> > >> 
> > >> Care to do a PR for this? Maybe it'd be best to check for both options
> > >> separately, so that if the -all option isn't available, we can still
> > >> use
> > >> the regular option.
> > > 
> > > I'm not sure I get what we would achieve with changing the
> > > "-fstack-protector" to "-fstack-protector-all", because the patch above,
> > > is the one that was creating the crash.
> > 
> > The way I interpret this is: it uncovers bugs, so it's worth having :)
> > Especially in this point of our dev cycle.
> 
> Hi,
> 
> I got the same segmentation fault again (I'm starting to think this happens
> only with very specific traffic, which is somewhat strange).
> 
> This time, Suricata was compiled with -fstack-protector (default behavior).
> I will disable the position independent code compilation (another thing I
> added) and see if it has any influence.
> 
> Cheers,
> Duarte Silva