Mailing List Archive

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

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

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

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

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 <file path>" 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

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" <markjallan@gmail.com> wrote:

>le output from the last "Scanning <file path>" 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

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