Bug #1694
closedunix-socket reading 0 size pcap
Description
Reading feeding 0 size pcap with unix-socket the engine (3.0dev (rev 44a444b)) stalls and eventually after some time crashes out with -
[14779] 4/2/2016 -- 22:03:07 - (tm-threads.c:1493) <Error> (TmThreadDisableReceiveThreads) -- [ERRCODE: SC_ERR_FATAL(171)] - Engine unable to disable detect thread - "ReceivePcapFile". Killing engine
While there is no valid reason to read an empty.pcap (attached) there should be some controls implemented in order to avoid that.
Updated by Victor Julien about 8 years ago
- Assignee set to OISF Dev
- Target version set to 70
Updated by Victor Julien about 8 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Eric Leblond
- Priority changed from Normal to Low
Empty 'pcap' is nothing more than a 0 byte file. Probably libpcap blocks while reading the file, and we use no read 'time out' in offline mode. Guess we could have an explicit check for this. Might make sense to check for the file to be at least the size of a pcap header.
Updated by Victor Julien about 8 years ago
- Target version changed from 70 to TBD
Updated by Danny Browning about 6 years ago
- Assignee changed from Eric Leblond to Danny Browning
Related to other work I'm doing around hardening unix socket pcaps, so assigning to myself.
Updated by Victor Julien about 5 years ago
- Related to Bug #2795: asan leak: processing of empty pcap added
Updated by Victor Julien about 5 years ago
- Priority changed from Low to Normal
- Target version changed from TBD to 70
Updated by Victor Julien about 5 years ago
Hi Danny, have you looked further into this?
Updated by Danny Browning about 5 years ago
The error was originally reported in 3.0, however in 4.1 the engine correctly shuts down when using the -r option.
[4611] 18/2/2019 -- 08:26:13 - (source-pcap-file-helper.c:174) <Error> (InitPcapFile) -- [ERRCODE: SC_ERR_FOPEN(44)] - truncated dump file; tried to read 4 file header bytes, only got 0 [4611] 18/2/2019 -- 08:26:13 - (source-pcap-file.c:276) <Warning> (ReceivePcapFileThreadInit) -- [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - Failed to init pcap file empty.pcap, skipping [775] 18/2/2019 -- 08:26:13 - (tm-threads.c:2127) <Error> (TmThreadWaitOnThreadInit) -- [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RX#01" failed to initialize: flags 0145 [775] 18/2/2019 -- 08:26:13 - (suricata.c:3033) <Error> (main) -- [ERRCODE: SC_ERR_INITIALIZATION(45)] - Engine initialization failed, aborting...
source-pcap-file is returning an error since init failed, and then we get a thread init error message due to this.
[775] 18/2/2019 -- 08:26:13 - (tm-threads.c:2127) <Error> (TmThreadWaitOnThreadInit) -- [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RX#01" failed to initialize: flags 0145
This behavior feels correct, but we could check the size of the file and produce a little clearer output.
Updated by Victor Julien about 5 years ago
- Status changed from Assigned to Closed
- Assignee deleted (
Danny Browning) - Target version deleted (
70)
Thanks for checking Danny!
Updated by Danny Browning about 5 years ago
In unix socket mode, this produces a segfault in 4.1, since the thread errors.
So 2 options- Check for 0 size files and don't fail the init, just report an error message and return ok
- Figure out why an init failure causes a segfault
Updated by Victor Julien about 5 years ago
- Status changed from Closed to Assigned
- Assignee set to Danny Browning
- Target version set to 70
Ah ok, reopening because of that.
I think there are more ways in which opening a pcap can fail, so we probably need a more generic way to handle it than just a 0 size check.
Updated by Danny Browning about 5 years ago
Updated by Victor Julien about 5 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 5.0beta1
Updated by Victor Julien about 4 years ago
- Related to Bug #3448: Suricata 4.1 Seg Fault: Socket Control pcap-file and corrupt pcap added