[Clamav-devel] Why is error 13 fatal?

[Steven Morgan]

Mark,

To clarify, this patch allows the scan of the current file to continue.
ClamAV is not aborting scans of subsequent files, right?

THanks,
Steve


On Mon, Oct 30, 2017 at 1:03 PM, Mark Allan <markjallan at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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
>