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 <smor...@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 <markjal...@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) <micas...@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-boun...@lists.clamav.net] On
>> Behalf Of Mark Allan
>>> Sent: Friday, October 27, 2017 10:44 AM
>>> To: ClamAV Development <clamav-devel@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
