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
Updated by Jim Thompson almost 8 years ago
- Assignee set to Luiz Souza
- Priority changed from Normal to Low
Updated by Jim Pingle almost 8 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
Updated by Kill Bill over 7 years ago
I just submitted a crash dump related to this (IP: 85.70.xx.xx)
Updated by Jim Pingle over 7 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.
Updated by Kill Bill over 7 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.
Updated by Luiz Souza over 7 years ago
- Target version changed from 2.4.0 to 2.4.1
Updated by Jim Pingle about 7 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
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.2 to 2.4.3
Updated by Jim Pingle almost 7 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 6 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.