segfault at 000000000311c000 rip 000000000040fb46rsp 0000007fbffff830 error 4

[Gunnar Lindberg]

I'm sorry that this is very incomplete, but it's as far as I got.
Confusing - or worse.  Source code, with line numbers, below.

Before that, however: It seems like Argus is trying to decode packets
quite extensivly, going into every corner of IP_in_IP_in_IP etc. For
some usage this is probably what people want. Our usage is much less
advanced (in that respect) and we'd be quite happy to see that X and Y
communicated via protocal P (icmp, udp, tcp, ip_51, etc). Has anyone
thought of the possibility to control such "decoding depths" - like in
"tcpdump -{q|v}"?


May 19 15:25:31 argv kernel: argus[18775]:
    segfault at 0000007fc09ff770 rip 00000000004140b4
    rsp 0000007fbffff5c0 error 6

# gdb argus core.18775
(gdb) bt
#0 0x00000000004140b4 in ArgusGetPackets (src=0x2a95786010)
   at ArgusSource.c:2181
#1 0x0000000000404c77 in main (argc=1, argv=0x7fbffffe08) at argus.c:535

(gdb) print i
$1 = 1
(gdb) print found
$1 = 2
(gdb) print fd
$1 = 83886085
(gdb) print fds
$2 = {4, 83886085, -1, -1, -1}

So, it seems to be a file descriptor is way out of range and it seems
likely that FD_SET() may choke on that. Primary question is: Is this
data modyfied within some internal pcap_fileno() data structure or
within Argus? "struct ArgusSourceStruct *src" - many bytes...

Boy, I must admit I'm impressed by gdb :-)

(gdb) print *src
...
ArgusInterfaces = 2,
...
src->ArgusInterface[0].ArgusPd ==  4
src->ArgusInterface[0].ArgusCallBack == ArgusEtherPacket()

src->ArgusInterface[1].ArgusPd ==  83886085 (0x05000005)
src->ArgusInterface[1].ArgusCallBack == ArgusEtherPacket()

So, one way or the other we've been able to write into Argus data
and destroy the file descriptor that was OK some time before (there
is an identical call to FD_SET() on line 2023 - which we obviously
survived.

And, at line 2041 we're calling some kind of parser routine; my
0.01c is that somewhere in that code a pointer goes haywire. Which
pointer, how and why remains to be understood. Next week :-)?

	Gunnar Lindberg, Chalmers

argus/ArgusSource.c
   1982 ArgusGetPackets (struct ArgusSourceStruct *src)
   1983 {

   2023                FD_SET(pcap_fileno(src->ArgusInterface[i].ArgusPd), &ArgusReadMask);

   2041                   src->ArgusInterface[0].ArgusCallBack((char *)src, header, pkt_data);


   2174                for (i = 0; i < src->ArgusInterfaces; i++) {
   2175                   if (src->ArgusInterface[i].ArgusPd && ((fd = pcap_fileno(src->ArgusInterface[i].ArgusPd)) >= 0)) {
   2176                      found++;
   2177                      fds[i] = fd;
   2178 
   2179                      if (src->ArgusInterface[i].ifr.ifr_flags & IFF_UP)  {
   2180                         up++;
   2181             ===>>>      FD_SET(pcap_fileno(src->ArgusInterface[i].ArgusPd), &ArgusReadMask);
   2182                         if (width < pcap_fileno(src->ArgusInterface[i].ArgusPd))
   2183                            width = pcap_fileno(src->ArgusInterface[i].ArgusPd);
   2184                      }
   2185 
   2186                   } else {


>From Gunnar.Lindberg at chalmers.se  Tue May 19 12:17:45 2009
>Date: Tue, 19 May 2009 12:17:37 +0200 (MEST)
>Message-Id: <200905191017.n4JAHbZs007010 at grunert.cdg.chalmers.se>
>From: Gunnar Lindberg <Gunnar.Lindberg at chalmers.se>
>To: carter at qosient.com
>Subject: Re: [ARGUS] segfault at 000000000311c000 rip 000000000040fb46rsp	0000007fbffff830 error 4
>Cc: argus-info at lists.andrew.cmu.edu, vanepp at sfu.ca
>In-Reply-To: <C46F56C8-4BD3-4B1E-BAC7-A64E4F0B4145 at qosient.com>

>...