[Oisf-devel] Segfault in 1.0.5

[Joel Ebrahimi]

Hi Victor,

max_pending_packets is indeed being set to 0, thereby setting
pcap_max_read_packets to 0. If this is all going away then it is
probably not worth the effort to determine the cause.

// Joel 

-----Original Message-----
From: oisf-devel-bounces at openinfosecfoundation.org
[mailto:oisf-devel-bounces at openinfosecfoundation.org] On Behalf Of
Victor Julien
Sent: Wednesday, August 31, 2011 12:12 AM
To: oisf-devel at openinfosecfoundation.org
Subject: Re: [Oisf-devel] Segfault in 1.0.5

Hey Joel,

On 08/31/2011 12:20 AM, Joel Ebrahimi wrote:
> I have been having problems with segfaulting since using the 1.0.2 
> branch but I have not had time to find out if it was Bivio related or 
> something in Suricata until now. I have indentified the problem, 
> though Im not sure why no one using pcap to grab packets has reported 
> this before. Here is a breakdown of the problem:
> 
>  
> 
> When the pcap_dispatch function is called, the cnt field is evaluated 
> by the conditional operator "(pcap_max_read_packets < packet_q_len) ?
> pcap_max_read_packets : packet_q_len". In my case this results in 0, 
> which when passed into pcap_dispatch means to grab all the packets in 
> the queue or until an error occurs. When I start suricata and run 
> traffic at high speeds, there is generally around 20,000 packets 
> already in the queue.
> 
>  
> 
> The pcap handler function PcapCallback is called, it process all those

> 20,000 packets and stores them in the PcapThreadVars ptv->array. The 
> problem is that the array is allocated with the defined variable 
> PCAP_FILE_MAX_PKTS which has a value of 256. So ultimately I segfault 
> when accessing ptv->array when the index is greater than 256.
> 
>  
> 
> The solution would be either to restrict cnt in pcap_dispatch to 256 
> or change PCAP_FILE_MAX_PKTS. I found it easier for me to just change 
> PCAP_FILE_MAX_PKTS to 65536. When changed I do not experience any more

> segfaulting.

The ReceivePcapThreadInit function should make sure
pcap_max_read_packets is either set to PCAP_FILE_MAX_PKTS or to
"max_pending_packets", whichever is lower. Can you confirm that it isn't
0? See attached patch.

Then at runtime packet_q_len should never be 0 when pcap_dispatch is
called. Attached patch checks for that explicitly as well.

Please check the patch.

Btw, in our git master we're doing some serious reworking of the logic
to get rid of that dreaded array. Should be better and faster too.

See
https://redmine.openinfosecfoundation.org/projects/suricata/repository/r
evisions/b753ecce508340cd58cf7cdecce955c6864a4705/entry/src/source-pcap-
file.c
then the ReceivePcapFileLoop function. It's still to be implemented for
pcap live mode.

Cheers,
Victor

--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------