Package: conntrackd
Version: 1:1.2.1-1+deb7u1
Severity: important
Tags: upstream
Hi,
I'm hitting a SEGFAULT in conntrackd.
By now, I ignore if the problem is solved in unstable or upstream.
I will report this upstream myself. Will do soon some tests with
the latest version in unstable as well.
More information (I don't know how to get the symbols resolved):
$ sudo valgrind conntrackd
==30764== Memcheck, a memory error detector
==30764== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30764== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30764== Command: conntrackd
==30764==
==30764== Invalid read of size 4
==30764== at 0x408F00: ??? (in /usr/sbin/conntrackd)
==30764== by 0x40957E: ??? (in /usr/sbin/conntrackd)
==30764== by 0x4050C4: ??? (in /usr/sbin/conntrackd)
==30764== by 0x4E3472E: __callback (in
/usr/lib/x86_64-linux-gnu/libnetfilter_conntrack.so.3.3.0)
==30764== by 0x504A04E: nfnl_step (libnfnetlink.c:1340)
==30764== by 0x504A7F2: nfnl_process (libnfnetlink.c:1385)
==30764== by 0x504AB65: nfnl_catch (libnfnetlink.c:1539)
==30764== by 0x404E0B: ??? (in /usr/sbin/conntrackd)
==30764== by 0x404A50: ??? (in /usr/sbin/conntrackd)
==30764== by 0x405E50: ??? (in /usr/sbin/conntrackd)
==30764== by 0x403C17: ??? (in /usr/sbin/conntrackd)
==30764== by 0x526BEAC: (below main) (libc-start.c:244)
==30764== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30764==
==30764==
==30764== Process terminating with default action of signal 11 (SIGSEGV)
==30764== Access not within mapped region at address 0x0
==30764== at 0x408F00: ??? (in /usr/sbin/conntrackd)
==30764== by 0x40957E: ??? (in /usr/sbin/conntrackd)
==30764== by 0x4050C4: ??? (in /usr/sbin/conntrackd)
==30764== by 0x4E3472E: __callback (in
/usr/lib/x86_64-linux-gnu/libnetfilter_conntrack.so.3.3.0)
==30764== by 0x504A04E: nfnl_step (libnfnetlink.c:1340)
==30764== by 0x504A7F2: nfnl_process (libnfnetlink.c:1385)
==30764== by 0x504AB65: nfnl_catch (libnfnetlink.c:1539)
==30764== by 0x404E0B: ??? (in /usr/sbin/conntrackd)
==30764== by 0x404A50: ??? (in /usr/sbin/conntrackd)
==30764== by 0x405E50: ??? (in /usr/sbin/conntrackd)
==30764== by 0x403C17: ??? (in /usr/sbin/conntrackd)
==30764== by 0x526BEAC: (below main) (libc-start.c:244)
==30764== If you believe this happened as a result of a stack
==30764== overflow in your program's main thread (unlikely but
==30764== possible), you can try to increase the size of the
==30764== main thread stack using the --main-stacksize= flag.
==30764== The main thread stack size used in this run was 8388608.
==30764==
==30764== HEAP SUMMARY:
==30764== in use at exit: 35,673 bytes in 286 blocks
==30764== total heap usage: 89,239 allocs, 88,953 frees, 26,350,033 bytes
allocated
==30764==
==30764== LEAK SUMMARY:
==30764== definitely lost: 1,582 bytes in 97 blocks
==30764== indirectly lost: 0 bytes in 0 blocks
==30764== possibly lost: 0 bytes in 0 blocks
==30764== still reachable: 34,091 bytes in 189 blocks
==30764== suppressed: 0 bytes in 0 blocks
==30764== Rerun with --leak-check=full to see details of leaked memory
==30764==
==30764== For counts of detected and suppressed errors, rerun with: -v
==30764== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
##########################################################################
(gdb) r
Starting program: /usr/sbin/conntrackd
Program received signal SIGSEGV, Segmentation fault.
0x0000000000408f00 in ?? ()
(gdb) bt
#0 0x0000000000408f00 in ?? ()
#1 0x000000000040957f in ?? ()
#2 0x00000000004050c5 in ?? ()
#3 0x00007ffff7bca72f in __callback () from
/usr/lib/x86_64-linux-gnu/libnetfilter_conntrack.so.3
#4 0x00007ffff79c204f in nfnl_step (h=h@entry=0x65be30,
nlh=nlh@entry=0x7fffffffb370) at libnfnetlink.c:1340
#5 0x00007ffff79c27f3 in nfnl_process (h=h@entry=0x65be30,
buf=buf@entry=0x7fffffffb370 "\030\001", len=len@entry=280) at
libnfnetlink.c:1385
#6 0x00007ffff79c2b66 in nfnl_catch (h=0x65be30) at libnfnetlink.c:1539
#7 0x0000000000404e0c in ?? ()
#8 0x0000000000404a51 in ?? ()
#9 0x0000000000405e51 in ?? ()
#10 0x0000000000403c18 in ?? ()
#11 0x00007ffff7652ead in __libc_start_main (main=<optimized out>,
argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>,
fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe778) at libc-start.c:244
#12 0x0000000000404465 in ?? ()
#13 0x00007fffffffe778 in ?? ()
#14 0x000000000000001c in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fffffffe982 in ?? ()
#17 0x0000000000000000 in ?? ()
Just a curiosity, the SEGFAULT happened almost at the same time as this:
$ sudo conntrack -E -s 192.168.3.123 -d 8.8.8.8
[NEW] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27482
[UNREPLIED] src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27482
[UPDATE] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27482
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27482
[DESTROY] icmp 1 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27455
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27455
[NEW] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27510
[UNREPLIED] src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27510
[UPDATE] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27510
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27510
[DESTROY] icmp 1 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27482
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27482
[DESTROY] icmp 1 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27510
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27510
[NEW] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27699
[UNREPLIED] src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27699
[UPDATE] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27699
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27699
[DESTROY] icmp 1 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27699
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27699
[NEW] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27728
[UNREPLIED] src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27728
[UPDATE] icmp 1 30 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27728
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27728
[DESTROY] icmp 1 src=192.168.3.123 dst=8.8.8.8 type=8 code=0 id=27728
src=8.8.8.8 dst=192.168.3.123 type=0 code=0 id=27728
[NEW] tcp 6 120 SYN_SENT src=192.168.3.123 dst=8.8.8.8 sport=36379
dport=80 [UNREPLIED] src=8.8.8.8 dst=192.168.3.123 sport=80 dport=36379
WARNING: We have hit ENOBUFS! We are losing events.
This message means that the current netlink socket buffer size is too small.
Please, check --buffer-size in conntrack(8) manpage.
conntrack v1.2.1 (conntrack-tools): Operation failed: No buffer space available
-- System Information:
Debian Release: 7.8
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages conntrackd depends on:
ii libc6 2.13-38+deb7u8
ii libnetfilter-conntrack3 1.0.1-1
ii libnfnetlink0 1.0.0-1.1
conntrackd recommends no packages.
conntrackd suggests no packages.
-- Configuration Files:
/etc/conntrackd/conntrackd.conf changed:
Sync {
Mode NOTRACK {
DisableInternalCache on
DisableExternalCache on
}
TCP {
IPv4_address 172.16.0.1
IPv4_Destination_Address 172.16.0.2
Port 3780
Interface eth8
SndSocketBuffer 12492800
RcvSocketBuffer 12492800
Checksum on
}
Options {
ExpectationSync On
}
}
General {
Nice -20
Scheduler {
Type FIFO
Priority 99
}
HashSize 3276800
HashLimit 131072000
LogFile on
LockFile /var/lock/conntrackd.lock
UNIX {
Path /var/run/conntrackd.sock
Backlog 20
}
NetlinkBufferSize 8388608
NetlinkBufferSizeMaxGrowth 8388608
SocketBufferSize 8388608
SocketBufferSizeMaxGrown 8388608
Filter {
Address Ignore {
# a set of ~50 IPv4/IPv6 addresses
}
}
}
/etc/default/conntrackd changed:
CONFIG=/etc/conntrackd/conntrackd.conf
/etc/logrotate.d/conntrackd changed:
/var/log/conntrackd*.log {
weekly
rotate 2
missingok
}
-- no debconf information
