Hello , thanks for the report 

Could you describe a little more what setup do you have ? 
rpm -qa | grep clam ? 

clamd.exim.service is not provide by any clamav packages ... , I suspect is something new (only on F28 )

clamd.exim.service comes from the exim-clamav package, which is built as part of the exim MTA.  The package provides the following files:

/etc/clamd.d/exim.conf
/etc/logrotate.d/clamd.exim
/etc/sysconfig/clamd.exim
/usr/lib/systemd/system/clamd.exim.service
/usr/lib/tmpfiles.d/exim-clamav.conf
/usr/sbin/clamd.exim
/var/log/clamd.exim
/var/run/clamd.exim

/etc/clamd.d/exim.conf contains only the following (after removing comments and blank lines:

LogFile /var/log/clamd.exim
LogSyslog yes
PidFile /var/run/clamd.exim/clamd.pid
LocalSocket /var/run/clamd.exim/clamd.sock
User exim
AllowSupplementaryGroups yes

If something in the exim package needs to change in order to support the updated clamav package, please let me know what it is so that I can work with the exim maintainers to accommocate.  I haven't yet tried 0.100 in my standard exim setup.

However, given that clamav is exiting with SIGABRT, this seems like it might be unrelated to exim or the exim configuration of clamav.  I wonder if it drops a core.

Created attachment 1450887 [details]
libclamav-debug

debugging was enabled in /etc/clamd.d/exim.conf for libclamav not sure if it is of any value.

note I have downgraded back to 0.99 so I do not have 0.100 on the system, I can re-install it if necessary.

currently:
 rpm -qa | grep clam
clamav-data-0.99.4-3.fc28.noarch
clamav-update-0.99.4-3.fc28.x86_64
clamav-0.99.4-3.fc28.x86_64
clamav-filesystem-0.99.4-3.fc28.noarch
exim-clamav-4.91-1.fc28.x86_64
clamd-0.99.4-3.fc28.x86_64
clamav-lib-0.99.4-3.fc28.x86_64

from my dnf logs the following was installed:
  clamav.x86_64 0.100.0-2.fc28              clamav-data.noarch 0.100.0-2.fc28
  clamav-filesystem.noarch 0.100.0-2.fc28   clamav-lib.x86_64 0.100.0-2.fc28
  clamav-update.x86_64 0.100.0-2.fc28       clamd.x86_64 0.100.0-2.fc28

I started clamav with debugging enabled for libclamav (output attached) not sure if it is of any value.

We're really going to need the clamd corefile to figure this out.

give me instructions on how to obtain the core file and I'll re-install 0.100 to obtain it.

Well, first just run coredumpctl and see if it captured anything.  If a core file is actually present then great.  From there you can take the PID of the core you want to inspect and do coredumpctl info [pid] to get some basic information about it.

I honestly don't know if systemd by default restricts coredumps from daemons in F28.  If it does, you can probably allow that globally by editing /etc/systemd/system.conf and adding DefaultLimitCORE=infinity

If there's an easier/simpler way, I'm sure someone will tell me.

I edited /etc/systemd/system.conf and added the line "DefaultLimitCORE=infinity" and sent a -HUP to systemd.  I then re-upgraded to clamav 0.100 and upon receiving the first email message clamav stopped.  I checked and there was no core file created.

I have now left clamav 0.100 installed, however I have disabled the av scanner in exim so it won't stop incoming email.

clamd configuration details -

/etc/sysconfig/clamd.exim contains:
CLAMD_CONFIG='/etc/clamd.d/exim.conf'
CLAMD_SOCKET=/var/run/clamd.exim/clamd.sock

The only uncommented lines in /etc/clamd.d/exim.conf are:

grep ^[^#] /etc/clamd.d/exim.conf  -

LogSyslog yes
PidFile /var/run/clamd.exim/clamd.pid
LocalSocket /var/run/clamd.exim/clamd.sock
User exim

I completely removed all traces of clamav, including the previous installation of the "unofficial" signatures and then reinstalled it again from the fedora repositories.  it appears to be working.

I suspect something with the unofficial signatures was the issue.

May be related:
https://github.com/extremeshok/clamav-unofficial-sigs/issues/203
https://github.com/extremeshok/clamav-unofficial-sigs/issues/204

Also, https://bugzilla.clamav.net/show_bug.cgi?id=12077 seems on-point.

I think this is a valid clamav bug but I don't know if there's any point in tracking it separately in Fedora.

yeah reopen it , we should try add a fix before update epel 7 and 6 to stable, 
unfortunately f27 package is already pushed to stable .

Thanks for the reports

Hello have we this problem with F27 , or with el7 or 6 ? 
i.e. the unofficial signatures are more update in F28, than others ? and that is the problem ?

I am pretty sure it would cause problems on any release; the bug is in clamav 0.100.  Reading the upstream bug report, it looks like the bug may have been present for far longer but was masked by clamav rejecting those rules for other reasons.

The only way you would see the problem, though, is if you use YARA rules which are malformed in a particular way.  And the only common way to get that is to configure a particular set of signatures from clamav-unofficial-sigs.  Personally I use signatures from clamav-unofficial-sigs and I don't have this problem, but that's because I haven't enabled the specific ones which cause the problem.  (Those seem to be EMAIL_Cryptowall.yar & antidebug_antivm.yar, as mentioned in https://github.com/extremeshok/clamav-unofficial-sigs/issues/203.)

The default configuration of clamav-unofficial-sigs in the version shipped by Fedora does not include the problematic signatures.  The upstream version (which is _way_ newer than what is packaged in Fedora does include them by default.

So basically anyone who just does dnf install clamav-unofficial-sigs won't have a problem, but if you add extra rules or manually install the upsteam clamav-unofficial-sigs and keep the defaults then you will.  I imagine the set of Fedora users who would see a problem would be pretty small, and certainly not significant enough try to undo the upgrade to 0.100.  It would certainly be worth patching if a patch were available.

According to the upstream ticket (https://bugzilla.clamav.net/show_bug.cgi?id=12077) this won't be fixed for the 0.100 series.  Interestingly I don't see any reports about this at the yara rules project upstream tracker (https://github.com/Yara-Rules/rules).  The two files in question haven't been touched in a while.  Someone more familiar with the issue might want to file a ticket with them.

(In reply to Jason Tibbitts from comment #14)
> So basically anyone who just does dnf install clamav-unofficial-sigs won't
> have a problem, but if you add extra rules or manually install the upsteam
> clamav-unofficial-sigs and keep the defaults then you will.  

OK , I fail to understand this more earlier , so I can close this bug as won't fix  ? and use "unofficial" signatures from the fedora/epel repositories .

And since we don't have any other bug report , we can push clamav-0.100 to stable , if nobody disagrees .

The bug is reported upstream [1]
and "unofficial" signatures from the fedora/epel repositories , have removed the problematic tests . 

[1]
https://bugzilla.clamav.net/show_bug.cgi?id=12077

Just a note that the Fedora clamav-unofficial-sigs package was recently updated, and the new package does have the YARA rules enabled by default and so anyone who gets the updated clamav-unofficial-sigs package will see this problem.

Note that I filed https://bugzilla.redhat.com/show_bug.cgi?id=1660590 against clamav-unofficial-sigs to hopefully get the YARA rules turned off by default.