[Clamav-devel] Why is error 13 fatal?

[Mark Allan]

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.


> On 30 Oct 2017, at 4:36 pm, Micah Snyder (micasnyd) <micasnyd at cisco.com> wrote:
> 
> Hi Mark,
> 
> I'm curious if there are any particular files that it scans that causes a seek to fail / causes the CL_ESEEK error to bubble up to that switch statement in magic_scandesc().  I wouldn't be surprised if an invalid offset in a file header caused a seek to an invalid offset.  I don't know if APFS handles seeks to offsets outside of the actual file differently than other file systems.  What is more typical is a read error if you seek outside of the file and then read.  Anyhow, if you can identify any samples that cause the issue I'd like to test with it. 
> 
> Can you send us your patch to tweak the switch statement for review?  I agree that a seek error in one file shouldn't halt the entire scan.   
> 
> Cheers,
> Micah
> 
> Micah Snyder
> Software Engineer
> Talos Intelligence
> Cisco Systems, Inc.
> 
> -----Original Message-----
> From: clamav-devel [mailto:clamav-devel-bounces at lists.clamav.net] On Behalf Of Mark Allan
> Sent: Friday, October 27, 2017 10:44 AM
> To: ClamAV Development <clamav-devel at lists.clamav.net>
> Subject: [Clamav-devel] Why is error 13 fatal?
> 
> 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
> 
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml