Bugzilla – Bug 11948
[Clamav-devel] Why is error 13 fatal?
Last modified: 2020-02-19 09:43:49 EST
This is from the clamav-devel mailing list: Mark Allan <markjallan@gmail.com> Oct 27 (4 days ago) to ClamAV Hi there, For a while now, ClamAV 0.99.2 has been terminating unexpectedly with error 13 when running on the latest version of OS X (macOS 10.13) but only on drives formatted with the new APFS, so I chalked it up to an APFS issue and reported it to Apple. Today, however, I received a report of the same thing from someone whose hard drive is formatted with the old standard HFS+. There's nothing of note in the scan output, even when run with --debug, and it gives the error at a different point every time. Sometimes it occurs after a couple of minutes, sometimes it can be an hour into the scan. I've had a look at the ClamAV source to see what's causing error 13 and it seems to correspond to CL_ESEEK. Looking in libclamav/scanners.c, I can see a switch statement that causes the scan to abort when the result from cli_scanraw(...) is CL_ESEEK. Can anyone think why the error would be occurring, and is there a particular reason why experiencing error 13 on one file should cause the rest of the scan to be aborted? Finally, is it safe to tweak that switch statement to log the error and continue scanning rather than stopping? It appears to work, but I'm not sure what knock-on effect it might have. Many thanks Mark ==================================================================== Mark Allan <markjallan@gmail.com> 1:03 PM (23 hours ago) to ClamAV Hi Micah, Thanks for getting back to me. Just so you know, I also received an email (off-list) from Tom McCourt about the same issue. Unfortunately I don't know what files are causing the issue because it seems to stop at a different point in the scan every time. Sometimes (rarely) the scan will even run to completion without giving the error. I'll run the scans again a few times this evening and pick out any files it stops on. Lastly, as requested, below is my patch for switch statement. (odd. I just noticed the CL_ESTAT case above ESEEK, has a comment at the end. That's unintentional) Thanks Mark diff -Naurw clamav-0.99.2_clean/libclamav/scanners.c clamav-0.99.2/libclamav/scanners.c --- clamav-0.99.2_clean/libclamav/scanners.c 2016-04-22 16:02:19.000000000 +0100 +++ clamav-0.99.2/libclamav/scanners.c 2016-10-17 16:13:57.000000000 +0100 @@ -3214,8 +3340,8 @@ switch(res) { /* List of scan halts, runtime errors only! */ case CL_EUNLINK: - case CL_ESTAT: - case CL_ESEEK: + case CL_ESTAT:// +// case CL_ESEEK: case CL_EWRITE: case CL_EDUP: case CL_ETMPFILE: @@ -3242,6 +3368,11 @@ cli_dbgmsg("Descriptor[%d]: Continuing after cli_scanraw reached %s\n", fmap_fd(*ctx->fmap), cl_strerror(res)); break; + case CL_ESEEK: + res = CL_CLEAN; + ret = res; + cli_errmsg("Descriptor[%d]: Continuing after cli_scanraw SEEK error %s\n", fmap_fd(*ctx->fmap), cl_strerror(res)); + break; /* Other errors must not block further scans below * This specifically includes CL_EFORMAT & CL_EREAD & CL_EUNPACK * Malformed/truncated files could report as any of these three.
Targeting for 0.99.3 if we can identify the issue in time.
See the mailing list archive for additional emails and attachments: http://lists.clamav.net/pipermail/clamav-devel/2017-October/000348.html
I have tried testing scanning a large number of files on an APFS formatted external drive under MacOS 10.13 and have been unable to replicate the issue.
From my own testing, the machine needs to be booted from an APFS volume (i.e. root should be APFS formatted) and clamscan should be scanning the root/boot volume.
Also, the output is not going directly to the console; it's being piped into another process.
Ok *awkward pause* ... unbeknownst to me, upgrading to 10.13 upgrades the format of the drive to APFS (reference: https://en.wikipedia.org/wiki/Apple_File_System#macOS). I didn't expect that it could the format in-place. Either way, my Macbook is now reporting Macintosh HD as APFS Volume • APFS. I ran a scan post-haste this morning using just a basic clamscan command as my normal user. clamscan -riv / My scan completed after a couple hours with the Scan Summary: ----------- SCAN SUMMARY ----------- Known viruses: 6328685 Engine version: devel-clamav-0.99-beta1-814-g40451e2ee Scanned directories: 139493 Scanned files: 896107 Infected files: 324 Total errors: 468 Data scanned: 43540.22 MB Data read: 425379.95 MB (ratio 0.10:1) Time: 8237.451 sec (137 m 17 s) (Yes, I have a lot of malware samples on this machine). Anyhow, I think I need further clarification. Are you running this with clamd as the clamav user? If not, are you using sudo or root privs to run clamscan so it scans as much as possible (with exception to anything that would restricted by System Integrity Protection).
He mentioned that it was a clamscan. Below is what he uses clamscan -riv --phishing-scan-urls=no --exclude-dir=/Users/mark/.Trash --exclude-dir=/Users/mark/Library/Mail --exclude-dir=/Users/mark/Documents/Microsoft User Data/Office 2011 Identities --exclude-dir=^/Volumes --exclude-dir=^/dev --exclude-dir=^/net --scan-mail=no --file-list=tempfile
Oh right sorry about that. I'll give it another go with that command.
(substituting my own username, and using / instead of --file-list). On the whole, sounds like the same scan but with some exclusions. Can't hurt to try again though.
So, as I mentioned previously, the output is not going directly to the console; it's being piped into another process. It turns out that this is only happening when the clamscan output is being piped into that other process. Also, I'm still seeing the error occasionally even with that patch applied, so something else must be triggering the CL_ESEEK error. Is it possible that this error is occurring when trying to write to stdout/stderr rather than when attempting to read a file? i.e. Could this be what happens if the pipe (output file handle) gets closed unexpectedly by the consuming process?
Sorry about the delay, Mark. I don't have an answer for you. I tried to replicate a simplistic analogue to what you're doing by piping my clamscan output to "tail -f" and then tried killing the tail process but didn't get the sort of error you received. Instead, the kill signal just passed up the chain to clamscan. Maybe it the tail -f somehow received a seek error I'd see something similar? I... really don't know.
The problem can no longer be replicated. Closing ticket.