Bug #7079
closedClamAV C-ICAP causing Kernel Panic and System Crash
0%
Description
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
Files
JT Updated by Jim Thompson over 9 years ago
- Assignee set to Luiz Souza
- Priority changed from Normal to Low
JP Updated by Jim Pingle over 9 years ago
I suspect this is not actually from clamav but that is what generates enough load in your environment to trigger it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807
Could be related to #7149 based on the comments on the FreeBSD bug report
KB Updated by Kill Bill over 9 years ago
I just submitted a crash dump related to this (IP: 85.70.xx.xx)
JP Updated by Jim Pingle over 9 years 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.
KB Updated by Kill Bill over 9 years 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.
LS Updated by Luiz Souza about 9 years ago
- Target version changed from 2.4.0 to 2.4.1
JP Updated by Jim Pingle almost 9 years 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
JP Updated by Jim Pingle almost 9 years ago
- Target version changed from 2.4.2 to 2.4.3
JP Updated by Jim Pingle over 8 years ago
- Status changed from New to Feedback
- Target version changed from 2.4.3 to 2.4.4
Still waiting on testing/confirmation feedback on a current version
Updated by Anonymous over 8 years ago
- Status changed from Feedback to Closed
- Target version deleted (
2.4.4)
Marking this closed due to lack of feedback. If you believe this should be reopened, please let us know.