[Clamav-devel] Why is error 13 fatal?

Steven Morgan smorgan at sourcefire.com
Tue Oct 31 12:51:57 EDT 2017


I have opened bugzilla ticket 11948 (
https://bugzilla.clamav.net/show_bug.cgi?id=11948 ) for tracking this issue.

Steve

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

> Hi Steve,
>
> No, this patch is designed to permit scans of subsequent files to
> proceed.  When error 13 is encountered, the whole clamscan process
> terminates.
>
> Mark
>
> > On 30 Oct 2017, at 7:43 pm, Steven Morgan <smorgan at sourcefire.com>
> wrote:
> >
> > 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
> >>
> > _______________________________________________
> > 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
>



More information about the clamav-devel mailing list