[Oisf-devel] suricata 1.3.4 coredump caused by segfault

Thu Nov 29 07:50:33 UTC 2012

Hi,

I was running suricata 1.3.4 and recently I got several coredump files. I
hope I can do some help to improve suricata.

I was compiled with:

./configure --enable-nfqueue --prefix=/usr --sysconfdir=/etc
--localstatedir=/var

Cmdline is:

/usr/bin/suricata -D -c /etc/suricata/suricata.yaml -i bridge1

‘bridge1’ is a simple bridge with 2 nics. And we have some Internet traffic
on it.

My ‘suricata.yaml’ file is almost not changed. And my HOME_NET is any.

I was using rules from EmergingThreats.

The following is the backtrace stack may help you.

Program terminated with signal 11, Segmentation fault.

[New process 2725]

[New process 2661]

[New process 2726]

[New process 2728]

[New process 2729]

[New process 2724]

[New process 2727]

[New process 2722]

[New process 2720]

[New process 2721]

[New process 2723]

#0  0x0810b759 in SCACSearch (mpm_ctx=0xc42bf48, mpm_thread_ctx=0xcde8cac,
pmq=0xcde8cc4, buf=0x0, buflen=28919) at util-mpm-ac.c:1232

1232    util-mpm-ac.c: No such file or directory.

        in util-mpm-ac.c

(gdb) bt

#0  0x0810b759 in SCACSearch (mpm_ctx=0xc42bf48, mpm_thread_ctx=0xcde8cac,
pmq=0xcde8cc4, buf=0x0, buflen=28919) at util-mpm-ac.c:1232

#1  0x08090047 in HttpServerBodyPatternSearch (det_ctx=0xcde8c58, body=0x0,
body_len=<value optimized out>, flags=10 '\n')

    at detect-engine-mpm.c:359

#2  0x0809cbfa in DetectEngineRunHttpServerBodyMpm (de_ctx=0xb2231c8,
det_ctx=0xcde8c58, f=0x4979c198, htp_state=0x7e21f350,

    flags=10 '\n') at detect-engine-hsbd.c:248

#3  0x08077a8a in SigMatchSignatures (th_v=0xb6fa7b30, de_ctx=0xb2231c8,
det_ctx=0xcde8c58, p=0xadcb980) at detect.c:1264

#4  0x08077b72 in Detect (tv=0xb6fa7b30, p=0xadcb980, data=0xcde8c58,
pq=0xb6fa7ca8, postpq=0x0) at detect.c:1995

#5  0x0814e234 in TmThreadsSlotVarRun (tv=0xb6fa7b30, p=0xadcb980,
slot=0xb6fa7bb0) at tm-threads.c:508

#6  0x0814e4ec in TmThreadsSlotVar (td=0xb6fa7b30) at tm-threads.c:732

#7  0xb765d4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0

#8  0xb759484e in clone () from /lib/i686/cmov/libc.so.6

(gdb)

The following is the other one:

Program terminated with signal 11, Segmentation fault.

[New process 28453]

[New process 28456]

[New process 28455]

[New process 28421]

[New process 28458]

[New process 28457]

[New process 28454]

[New process 28451]

[New process 28450]

[New process 28459]

[New process 28452]

#0  0xb78996d3 in table_add () from /usr/lib/libhtp-0.2.so.1

(gdb) bt

#0  0xb78996d3 in table_add () from /usr/lib/libhtp-0.2.so.1

#1  0xb78960e4 in htp_process_response_header_generic () from
/usr/lib/libhtp-0.2.so.1

#2  0xb789c389 in htp_connp_RES_HEADERS () from /usr/lib/libhtp-0.2.so.1

#3  0xb789b4e9 in htp_connp_res_data () from /usr/lib/libhtp-0.2.so.1

#4  0x08186030 in HTPHandleResponseData (f=0x670c6f00, htp_state=0x9f122e8,
pstate=0xb1eac20,

    input=0xb322d8e0 "HTTP/1.1 302 Found\r\nDate: Thu, 29 Nov 2012 02:25:50
GMT\r\nServer: Tencent Login Server/2.0.0\r\nLocation:
http://www.qq.com\r\nConnection:
Close\r\nContent-Type: text/html\r\n\r\n0\r\n\r\nring .logo {
background-pos"..., input_len=173,

    local_data=0x0, output=0xb322d800) at app-layer-htp.c:750

#5  0x0817fba6 in AppLayerDoParse (local_data=0x0, f=0x670c6f00,
app_layer_state=0x9f122e8, parser_state=0xb1eac20,

    input=0xb322d8e0 "HTTP/1.1 302 Found\r\nDate: Thu, 29 Nov 2012 02:25:50
GMT\r\nServer: Tencent Login Server/2.0.0\r\nLocation:
http://www.qq.com\r\nConnection:
Close\r\nContent-Type: text/html\r\n\r\n0\r\n\r\nring .logo {
background-pos"..., input_len=173,

    parser_idx=<value optimized out>, proto=1) at app-layer-parser.c:726

#6  0x0817fea1 in AppLayerParse (local_data=0x0, f=0x670c6f00, proto=<value
optimized out>, flags=10 '\n',

    input=0xb322d8e0 "HTTP/1.1 302 Found\r\nDate: Thu, 29 Nov 2012 02:25:50
GMT\r\nServer: Tencent Login Server/2.0.0\r\nLocation:
http://www.qq.com\r\nConnection:
Close\r\nContent-Type: text/html\r\n\r\n0\r\n\r\nring .logo {
background-pos"..., input_len=173)

    at app-layer-parser.c:935

#7  0x0816d5f7 in StreamTcpReassembleAppLayer (tv=0xb70007f0,
ra_ctx=0xb2900c28, ssn=0x3d4b1b88, stream=0x3d4b1b8c, p=0x99e3db0)

    at stream-tcp-reassemble.c:2942

#8  0x0816d813 in StreamTcpReassembleHandleSegmentUpdateACK (tv=0xb70007f0,
ra_ctx=0xb2900c28, ssn=0x3d4b1b88, stream=0x3d4b1b8c,

    p=0x99e3db0) at stream-tcp-reassemble.c:3310

#9  0x0816f2df in StreamTcpReassembleHandleSegment (tv=0xb70007f0,
ra_ctx=0xb2900c28, ssn=0x3d4b1b88, stream=0x3d4b1bc4, p=0x99e3db0,

    pq=0xb2900500) at stream-tcp-reassemble.c:3384

#10 0x08168ac3 in StreamTcpPacketStateFinWait1 (tv=0xb70007f0, p=0x99e3db0,
stt=0xb29004f8, ssn=0x3d4b1b88, pq=0xb2900500)

    at stream-tcp.c:2264

#11 0x0816a1af in StreamTcpPacket (tv=0xb70007f0, p=0x99e3db0,
stt=0xb29004f8, pq=0xb7000890) at stream-tcp.c:3517

#12 0x0816b3ff in StreamTcp (tv=0xb70007f0, p=0x99e3db0, data=0xb29004f8,
pq=0xb7000890, postpq=0xb70008e4) at stream-tcp.c:3752

#13 0x0814e234 in TmThreadsSlotVarRun (tv=0xb70007f0, p=0x99e3db0,
slot=0xb7000870) at tm-threads.c:508

#14 0x0814e4ec in TmThreadsSlotVar (td=0xb70007f0) at tm-threads.c:732

#15 0xb78184c0 in start_thread () from /lib/i686/cmov/libpthread.so.0

#16 0xb774f84e in clone () from /lib/i686/cmov/libc.so.6

(gdb)

For the coredump file is very large (>3GB), so if you want more information
please reply me. I am happy to see the improvement of suricata.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20121129/eea87257/attachment.html>