Actions
Bug #3118
closedasan leaks with 5.0.0-dev (9e126b210 2019-08-07)
Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:
Description
Compiled like:
git clone https://github.com/OISF/suricata.git && cd suricata && \ git clone https://github.com/OISF/libhtp.git -b 0.5.x && ./autogen.sh && \ ./configure --prefix=/opt/suritest-asan/ --sysconfdir=/opt/suritest-asan/etc \ --localstatedir=/opt/suritest-asan/var \ CFLAGS="-ggdb3 -Werror -Wchar-subscripts -fno-strict-aliasing -fstack-protector-all -fsanitize=address -fno-omit-frame-pointer -Wno-unused-parameter -Wno-unused-function" ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \ --enable-geoip --enable-rust-strict --enable-luajit && \ make clean && make -j && make install && \ make install && make install-full && ldconfig
run like:
time LSAN_OPTIONS=suppressions=suricata/qa/lsan.suppress ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-8/bin/llvm-symbolizer \ > /opt/suritest-asan/bin/suricata -k none -r qa.pcap --set "flow.memcap=8gb" \ > --set "stream.memcap=6gb" --set stream.reassembly.memcap=10gb --set max-pending-packets=20000 \ > -l log/ --runmode=autofp -S "rules/*.rules" [2214] 18/8/2019 -- 10:33:12 - (suricata.c:1071) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (3a912446a 2019-07-22) running in USER mode [2214] 18/8/2019 -- 10:35:43 - (tm-threads.c:2145) <Notice> (TmThreadWaitOnThreadInit) -- all 9 packet processing threads, 4 management threads initialized, engine started. [2214] 18/8/2019 -- 11:15:56 - (suricata.c:2851) <Notice> (SuricataMainLoop) -- Signal Received. Stopping engine. [2270] 18/8/2019 -- 11:49:54 - (source-pcap-file.c:378) <Notice> (ReceivePcapFileThreadExitStats) -- Pcap-file module read 1 files, 275652306 packets, 152382822719 bytes ================================================================= ==2214==ERROR: LeakSanitizer: detected memory leaks Direct leak of 64 byte(s) in 2 object(s) allocated from: #0 0x7f90ce0fdd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38) #1 0x5613529b108c in FTPCalloc /home/pevma/Work/tmp/suricata/src/app-layer-ftp.c:213 #2 0x5613529b43cb in FTPParseRequest /home/pevma/Work/tmp/suricata/src/app-layer-ftp.c:644 #3 0x5613529e2083 in AppLayerParserParse /home/pevma/Work/tmp/suricata/src/app-layer-parser.c:1210 #4 0x56135290a216 in AppLayerHandleTCPData /home/pevma/Work/tmp/suricata/src/app-layer.c:660 #5 0x561352e727e3 in ReassembleUpdateAppLayer /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1066 #6 0x561352e72c4b in StreamTcpReassembleAppLayer /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1123 #7 0x561352e7634d in StreamTcpReassembleHandleSegmentUpdateACK /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1689 #8 0x561352e76608 in StreamTcpReassembleHandleSegment /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1732 #9 0x561352e320f6 in HandleEstablishedPacketToClient /home/pevma/Work/tmp/suricata/src/stream-tcp.c:2375 #10 0x561352e34b1e in StreamTcpPacketStateEstablished /home/pevma/Work/tmp/suricata/src/stream-tcp.c:2612 #11 0x561352e50beb in StreamTcpStateDispatch /home/pevma/Work/tmp/suricata/src/stream-tcp.c:4617 #12 0x561352e5224d in StreamTcpPacket /home/pevma/Work/tmp/suricata/src/stream-tcp.c:4798 #13 0x561352e53e4f in StreamTcp /home/pevma/Work/tmp/suricata/src/stream-tcp.c:5134 #14 0x561352ca5443 in FlowWorker /home/pevma/Work/tmp/suricata/src/flow-worker.c:231 #15 0x561352ea0b8e in TmThreadsSlotVarRun /home/pevma/Work/tmp/suricata/src/tm-threads.c:128 #16 0x561352ea2ee5 in TmThreadsSlotVar /home/pevma/Work/tmp/suricata/src/tm-threads.c:585 #17 0x7f90cc4f26da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da) Indirect leak of 18 byte(s) in 2 object(s) allocated from: #0 0x7f90ce0fdd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38) #1 0x5613529b108c in FTPCalloc /home/pevma/Work/tmp/suricata/src/app-layer-ftp.c:213 #2 0x5613529b4473 in FTPParseRequest /home/pevma/Work/tmp/suricata/src/app-layer-ftp.c:649 #3 0x5613529e2083 in AppLayerParserParse /home/pevma/Work/tmp/suricata/src/app-layer-parser.c:1210 #4 0x56135290a216 in AppLayerHandleTCPData /home/pevma/Work/tmp/suricata/src/app-layer.c:660 #5 0x561352e727e3 in ReassembleUpdateAppLayer /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1066 #6 0x561352e72c4b in StreamTcpReassembleAppLayer /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1123 #7 0x561352e7634d in StreamTcpReassembleHandleSegmentUpdateACK /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1689 #8 0x561352e76608 in StreamTcpReassembleHandleSegment /home/pevma/Work/tmp/suricata/src/stream-tcp-reassemble.c:1732 #9 0x561352e320f6 in HandleEstablishedPacketToClient /home/pevma/Work/tmp/suricata/src/stream-tcp.c:2375 #10 0x561352e34b1e in StreamTcpPacketStateEstablished /home/pevma/Work/tmp/suricata/src/stream-tcp.c:2612 #11 0x561352e50beb in StreamTcpStateDispatch /home/pevma/Work/tmp/suricata/src/stream-tcp.c:4617 #12 0x561352e5224d in StreamTcpPacket /home/pevma/Work/tmp/suricata/src/stream-tcp.c:4798 #13 0x561352e53e4f in StreamTcp /home/pevma/Work/tmp/suricata/src/stream-tcp.c:5134 #14 0x561352ca5443 in FlowWorker /home/pevma/Work/tmp/suricata/src/flow-worker.c:231 #15 0x561352ea0b8e in TmThreadsSlotVarRun /home/pevma/Work/tmp/suricata/src/tm-threads.c:128 #16 0x561352ea2ee5 in TmThreadsSlotVar /home/pevma/Work/tmp/suricata/src/tm-threads.c:585 #17 0x7f90cc4f26da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da) SUMMARY: AddressSanitizer: 82 byte(s) leaked in 4 allocation(s). real 77m4.883s user 340m49.133s sys 9m48.217s
Updated by Victor Julien over 5 years ago
- Status changed from New to Assigned
- Assignee set to Jeff Lucovsky
- Target version set to 70
Peter can you make sure Jeff has access to the pcap?
Updated by Peter Manev over 5 years ago
I've been trying to carve a pcap out of the original pcap (140GB) that I was able to generate this issue with. So far have been unsuccessful , for starters I tried to carve out just "ftp" traffic, the resulting pcap was much smaller but could not reproduce the issue. Will keep trying and update the issue here.
Updated by Jeff Lucovsky about 5 years ago
If this issue is reproducible, then I suggest we try patching the following function -- adding an assert
int StorageSetById(Storage *storage, const StorageEnum type, const int id, void *ptr) { #ifdef DEBUG BUG_ON(!storage_registraton_closed); #endif SCLogDebug("storage %p id %d", storage, id); if (storage == NULL) return -1; assert(storage[id] == NULL); // If not null, memory leak storage[id] = ptr; return 0; }
Updated by Jeff Lucovsky about 5 years ago
- Related to Bug #2458: memleak: gitmaster - 4.1.0-dev (rev c60decd) added
Updated by Jeff Lucovsky about 5 years ago
Great ... this is to test a hunch. This was a place where it looked like there could be a memory leak related to the expectation handling.
Updated by Peter Manev about 5 years ago
I dont see this any more on any runs that i tried.
Updated by Victor Julien about 5 years ago
- Status changed from Assigned to Closed
- Assignee deleted (
Jeff Lucovsky) - Target version deleted (
70)
Actions