Bug #7079

ClamAV C-ICAP causing Kernel Panic and System Crash

Added by Brenden Smerbeck 11 months ago. Updated 27 days ago.

Operating System
Target version:
Start date:
Due date:
% Done:


Affected Version:
Affected Architecture:


Running ClamAV causes sporadic kernel panics and resets with the following syntax:

panic: sbsndptr: sockbuf 0xfffff8006b399878 and mbuf 0xfffff800635b2900 clashing

textdump traces approx. 20 c-icap commands as such:

Tracing command c-icap pid 29510 tid 100398 td 0xfffff80016315500
sched_switch() at sched_switch+0x6cb/frame 0xfffffe008d4db730
mi_switch() at mi_switch+0xd2/frame 0xfffffe008d4db760
sleepq_catch_signals() at sleepq_catch_signals+0xb7/frame 0xfffffe008d4db7e0
sleepq_timedwait_sig() at sleepq_timedwait_sig+0x10/frame 0xfffffe008d4db810
_cv_timedwait_sig_sbt() at _cv_timedwait_sig_sbt+0x1c4/frame 0xfffffe008d4db880
seltdwait() at seltdwait+0xc7/frame 0xfffffe008d4db8d0
kern_poll() at kern_poll+0x296/frame 0xfffffe008d4dba70
sys_poll() at sys_poll+0x61/frame 0xfffffe008d4dba90
amd64_syscall() at amd64_syscall+0x4ce/frame 0xfffffe008d4dbbb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe008d4dbbb0
--- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x800d86d9a, rsp = 0x7fffffffe848, rbp = 0x7fffffffe880 ---

Reviewing ID's, the clashing buffer address ranges fall within c-icap
sockbuf 0xfffff8006b399878

101218                   S       select   0xfffff8006b35a1c0 c-icap

mbuf 0xfffff800635b2900
100805                   S       uwait    0xfffff800636d6180 c-icap

After one day, persistent boot loops until ClamAV is disabled. With ClamAV disabled, kernel panics cease and it resumes normal function

textdump attached

textdump.tar.0 - textdump crash report (72.5 KB) Brenden Smerbeck, 01/04/2017 06:47 PM


#1 Updated by Jim Thompson 11 months ago

  • Assignee set to Luiz Souza
  • Priority changed from Normal to Low

#2 Updated by Jim Pingle 10 months ago

I suspect this is not actually from clamav but that is what generates enough load in your environment to trigger it.

Could be related to #7149 based on the comments on the FreeBSD bug report

#3 Updated by Kill Bill 9 months ago

I just submitted a crash dump related to this (IP: 85.70.xx.xx)

#4 Updated by Jim Pingle 9 months ago

Nothing from that address but I see one at the right time that came in over IPv6 (2001:470:6e prefix). That looks to be something else (hardware maybe?) Lots of other errors happening and some corruption in the output where there shouldn't. Doesn't look related to this bug to me.

<118>pfSense (pfSense) 2.3.4-DEVELOPMENT amd64 Fri Mar 03 09:42:00 CST 2017
<118>Bootup complete
<6>pid 53574 (ntopng), uid 0: exited on signal 11 (core dumped)
<6>gif0: promiscuous mode disabled
<6>gif0: promiscuous mode enabled
<6>pid 89221 (ntopng), uid 0: exited on signal 11 (core dumped)
<6>gif0: promiscuous mode disabled
<6>gif0: promiscuous mode enabled
<6>pid 83168 (ntopng), uid 0: exited on signal 11 (core dumped)
<6>gif0: promiscuous mode disabled
<6>gif0: promiscuous mode enabled
<6>pid 17372 (ntopng), uid 0: exited on signal 11 (core dumped)
<6>gif0: promiscuous mode disabled
<6>pid 15378 (clamd), uid 106: exited on signal 11
<6>gif0: promiscuous mode enabled
<6>pid 91668 (netstat), uid 0: exited on signal 10
panic:`�tack ov�rflow detected; backtrace may be corrupted
cpuid =�0
KDB: enter: panic

Backtrace also looks wildly different.

#5 Updated by Kill Bill 9 months ago

Yeah, that'd be the one. OT: The ntopng thing is a disaster, can you bump it to 2.4.2017.01.20_1? It keeps crashing on every machine I have; perhaps there's some fix in newer snapshots.

#6 Updated by Luiz Souza 3 months ago

  • Target version changed from 2.4.0 to 2.4.1

#7 Updated by Jim Pingle about 1 month ago

  • Target version changed from 2.4.1 to 2.4.2

This should be re-tested on 2.4.0-RELEASE, the newer FreeBSD 11.1 base has a patch for that crash, I believe. Also it has ntopng 3.0.x

#8 Updated by Jim Pingle 27 days ago

  • Target version changed from 2.4.2 to 2.4.3

Also available in: Atom PDF