Re: [Clamav-devel] Why is error 13 fatal?
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 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
> 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
> 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.c2016-04-22
> >> 16:02:19.0 +0100
> >> +++ clamav-0.99.2/libclamav/scanners.c 2016-10-17 16:13:57.0
> >> +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
> >>
Re: [Clamav-devel] Why is error 13 fatal?
Hello Mark, Thank you, I will look into this. I did some test scans yesterday on 99.2 and 99.3 in mac OS X 10.13 but wasn’t lucky enough to generate the error that you are seeing. I Will continue to run more scans and see if happens. Thank you, Tom M On 10/31/17, 8:46 AM, "Mark Allan" wrote: >le output from the last "Scanning " to the end of the output. Of >particular note is Run 2, where the last line of out ___ 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
Re: [Clamav-devel] Why is error 13 fatal?
Hi folks,
I've attached the output from 3 scans, all of which were started at root (/)
with no other volumes mounted on the system.
I'm running the scans with parameters -riv (recursive, print infected only,
verbose) as well as --debug. The verbose flag prints out the name of each file
being scanned, and I *believe* it prints this before attempting to start the
scan of that file.
For each run, I grabbed the console output from the last "Scanning "
to the end of the output. Of particular note is Run 2, where the last line of
output was the one saying which file was being scanned (prior to that point,
the output was as you would expect) - no debug output at all to hint at where
it went wrong.
As usual, all three scans stopped at different points. I've tried rescanning
those three files, and they all complete successfully. Happy to send them on
to you anyway if you think it would help. Just let me know where to send them -
presumably they shouldn't be sent to the list?
Mark
Scanning /Users/REDACTED/Library/Caches/com.apple.iTunes/WebKitCache/Version
11/Records/0263F8C913F192735CDDD8EE8B35A24936B42423/Resource/DD1190DCEF293D02AFBC495AC16E312F168F5459-blob
LibClamAV debug: in cli_magic_scandesc (reclevel: 0/16)
LibClamAV debug: Recognized ASCII text
LibClamAV debug: cache_check: 3fc5799f5fe8bad9232972eda77d7ce3 is negative
LibClamAV debug: Matched signature for file type HTML data at 82243
LibClamAV debug: Matched signature for file type HTML data
LibClamAV debug: Matched signature for file type HTML data
LibClamAV debug: Matched signature for file type HTML data
LibClamAV debug: Matched signature for file type HTML data
LibClamAV debug: matcher_run: performing regex matching on full map:
2077664+78843(2156507) >= 2156507
LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex
/\x2epostMessage\s*\x28\s*([^\s]+)\x2edata\x2econcat\s*\x28\1\x2edata\s*\x29/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex
/\x2f\x2a\s+XPM\s+\x2a\x2f[^\x7b]*?\x7b\s*\x22\s*(\d+\s+){3}\d{4}/
LibClamAV debug: cli_pcre_scanbuf: checking (0>1)&(1>1)&(2>25); running regex
/.Write\s*\x28\s*vbCrlf[^\n\x29]+\x28\s*[\x22\x27][a-zA-Z0-9+/]{5,}[a-zA-Z0-9+/=]{1,2}[\x22\x27]\s*\x29\s*\x29\r\n/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1&(2>150); running regex /^(var
[a-z]{3,} = [\x22\x27].{1,3}[\x22\x27]\x3B\n)/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/ATF.{3}\xFF.{1}[\x80-\xFF].{4}[\x00-\x12][\x00-\x12][\x00-\x13]/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1&2; running regex
/\x28\x00\x00\x00[\x00-\xff][\x00-\xff]\x90[\x04-\xff]([\x00-\xff]{4})\x01\x00\x08\x00/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex
/(function\s[o0O]{6}\(\s*([o0O]{6})?(\s*,\s*[o0O]{6})*\s*\).*?){3,}/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex
/[\W_][a-z0-9]{4,16}\.js/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/SMG[\W_][0-9]{2,4}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/ATTACHMENT\-PP\.html/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/NEW\sOPEN\sTENDER\sREQUIREMENT\sFOR\sMIDDLE\sEAST\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/PTY\sLTD\-USD\s[\d]{2,5}\.[\d]{2}\-VALUE\.vbs/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/[a-zA-Z]{4,7}\s[a-zA-Z]{6,9}\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/[a-z]{4}\s[a-z]{4}\-[0-9]{3}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/[a-zA-Z]{5}\s[A-Z0-9]{8,12}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/SHIPPING\sDOCUMENT\sINV,\sPL,\sBL\s\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /P41014\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex
/BL[\W_][\w]{0,16}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /HUD\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/0\.72077800\s1489544882\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/Tax\sRefund\sForm\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/PROCESSO\s2\sVARA\.vbe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/DHL\sDelivery\sDocuments\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/49BHAGB\s398\#\sADVICE\sTT\s0477HF\sHSBC\sSLK\sBANK\.html/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/WF\.jar[\W_]JavaCrypt[\d]?\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex
/[A-Z]{2}[A-Z0-9]{4,20}\.js/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/Contract\sWFALASMA\-05\-17\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /P[\d]{5,10}\.zip/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/Shipment\sDocs_Customs\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex
/[A-Z]{6}\s[A-Z]{7}\s[A-Z]{7}\s[A-Z]{3}\s[A-Z]{9}\.pif/
LibClamAV debug: cli_pcr
Re: [Clamav-devel] Why is error 13 fatal?
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 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 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.c2016-04-22
>> 16:02:19.0 +0100
>> +++ clamav-0.99.2/libclamav/scanners.c 2016-10-17 16:13:57.0
>> +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)
>> 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
>>> 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 ru
Re: [Clamav-devel] Why is error 13 fatal?
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 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.c2016-04-22
> 16:02:19.0 +0100
> +++ clamav-0.99.2/libclamav/scanners.c 2016-10-17 16:13:57.0
> +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)
> 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
> > 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
Re: [Clamav-devel] Why is error 13 fatal?
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.c2016-04-22 16:02:19.0
+0100
+++ clamav-0.99.2/libclamav/scanners.c 2016-10-17 16:13:57.0 +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)
> 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
> 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/lis
Re: [Clamav-devel] Why is error 13 fatal?
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 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
[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
