ankit | 4 Nov 12:41 2005

clam-error.rar:Rar module failure

Hello sir thanks for ur help till now

in scanners.h and scanners.c I used functions like .83 instead of like
.84( *arec,*mrec instead of arec and mrec)

scanners.h   .83
int cli_magic_scandesc(int desc, const char **virname, long int *scanned,
const struct cl_node *root, const struct cl_limits *limits, unsigned int
options, int *arec, int *mrec);

scanners.h  .84
int cli_magic_scandesc(int desc, const char **virname, long int *scanned,
const struct cl_node *root, const struct cl_limits *limits, unsigned int
options, unsigned int arec, unsigned int mrec);

Now it is scanning for clam.rar and clam.cab as earlier
but not for clam-error.rar
it is giving virus for clam.rar and clam.cab
but Rar module failure for clam-error.rar

Please help me where can be the problem

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html

Tomasz Kojm | 4 Nov 15:18 2005
Picon

Re: clam-error.rar:Rar module failure

On Fri, 4 Nov 2005 17:11:14 +0530
"ankit" <ankit <at> efextra.com> wrote:

> Hello sir thanks for ur help till now
> 
> in scanners.h and scanners.c I used functions like .83 instead of like
> .84( *arec,*mrec instead of arec and mrec)
> 
> scanners.h   .83
> int cli_magic_scandesc(int desc, const char **virname, long int *scanned,
> const struct cl_node *root, const struct cl_limits *limits, unsigned int
> options, int *arec, int *mrec);
> 
> 
> scanners.h  .84
> int cli_magic_scandesc(int desc, const char **virname, long int *scanned,
> const struct cl_node *root, const struct cl_limits *limits, unsigned int
> options, unsigned int arec, unsigned int mrec);
[...]
>Please help me where can be the problem

Those versions are no longer supported.

--

-- 
   oo    .....         Tomasz Kojm <tkojm <at> clamav.net>
  (\/)\.........         http://www.ClamAV.net/gpg/tkojm.gpg
     \..........._         0DCA5A08407D5288279DB43454822DC8985A444B
       //\   /\              Fri Nov  4 15:17:12 CET 2005
(Continue reading)

Brian Bebeau | 11 Nov 23:18 2005
Picon

help needed on messageDedup routine


Could someone please explain how the messageDedup() routine
in libclamav/message.c is supposed to work? It doesn't seem
to actually be de-allocating anything.

It's spinning in the second for() loop. Since t2 is
defined as t1->t_next, how will the strcmp() of d1 and d2
ever be 0? I'm added some extra debugging statements, and
the lineUnlink() routine is never called, so "saved" is
always 0, so it keeps going through all the lines. If I'm
missing some subtle thing it's doing, please explain it
to me.

The problem we're having is with certain customer emails
that have very large text attachments (~250,000 lines),
especially Autocad files. We run ClamAV under qmail, so
the memory is limited by softlimit. It runs out of memory
with these large files, so it calls messageDedup() from
messageAddStr(). It then winds up doing a strcmp 250,000
times for *each* of the 250,000 lines.

It only happens on our 64bit boxes, and the ones that get
it worse have libc-2.3.5.so, the libc-2.3.3 boxes aren't
so bad.

Strangely, I can repeat it on my Redhat 9 box if I comment
out the perror("malloc_problem") call in cli_malloc().
Maybe the newer library fixes perror() so it doesn't
segfault in this case, which is what I've seen from the
core dumps.
(Continue reading)

Nigel Horne | 11 Nov 23:39 2005
Picon

Re: help needed on messageDedup routine

Brian Bebeau wrote:
> 
> Could someone please explain how the messageDedup() routine
> in libclamav/message.c is supposed to work? It doesn't seem
> to actually be de-allocating anything.
> 
> It's spinning in the second for() loop. Since t2 is
> defined as t1->t_next, how will the strcmp() of d1 and d2
> ever be 0?

If the two lines' contents are the same thus:

hello
world
world

--

-- 
Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Typesetter.
NJH Music, Barnsley, UK.  ICQ#20252325
njh <at> despammed.com http://www.bandsman.co.uk
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Brian Bebeau | 13 Nov 02:53 2005
Picon

Re: help needed on messageDedup routine

Nigel Horne wrote:
> Brian Bebeau wrote:
> 
>>
>> Could someone please explain how the messageDedup() routine
>> in libclamav/message.c is supposed to work? It doesn't seem
>> to actually be de-allocating anything.
>>
>> It's spinning in the second for() loop. Since t2 is
>> defined as t1->t_next, how will the strcmp() of d1 and d2
>> ever be 0?
> 
> 
> If the two lines' contents are the same thus:
> 
> hello
> world
> world

Oh, OK, gotcha. So it only deallocates duplicate lines?
So in practice it probably won't free up much space. Is
there any way to turn this off so large files don't take
so long? If not, I guess the only other way would be to
keep track of the number of lines in a message myself,
and not run it through ClamAV if it's past a certain
limit. Not optimal, but doable. Thanks for the
clarification.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html

(Continue reading)

Nigel Horne | 13 Nov 10:28 2005
Picon

Re: help needed on messageDedup routine

Brian Bebeau wrote:

> Nigel Horne wrote:
>
>> Brian Bebeau wrote:
>>
>>>
>>> Could someone please explain how the messageDedup() routine
>>> in libclamav/message.c is supposed to work? It doesn't seem
>>> to actually be de-allocating anything.
>>>
>>> It's spinning in the second for() loop. Since t2 is
>>> defined as t1->t_next, how will the strcmp() of d1 and d2
>>> ever be 0?
>>
>>
>>
>> If the two lines' contents are the same thus:
>>
>> hello
>> world
>> world
>
>
> Oh, OK, gotcha. So it only deallocates duplicate lines?
> So in practice it probably won't free up much space. Is
> there any way to turn this off so large files don't take
> so long?

Yes- fix your ulimit so that the routine doesn't need to be called.
(Continue reading)

Tomasz Kojm | 15 Nov 21:16 2005
Picon

Re: clamscan: --exclude dirs/files before descending/scanning them

On Thu, 15 Sep 2005 14:32:25 -0700
Eric Berggren <ericb <at> transmeta.com> wrote:

> The current implementation of --exclude (and --exclude-dir) performs the
> pruning AFTER descending/scanning those files.

That's not true for --exclude-dir.

> The problem for us is that one of the areas we scan is via NFS on a
> NetApp filer, and upon finding the built-in .snapshot directory (which
> holds daily read-only snapshots of this hiearchy), spends the next week
> traversing 30+ copies of the same files. --exclude (and --exclude-dir)
> doesn't help us as implemented.
> 
> Attached is a patch we've been using since 0.75 (this one against
> 0.86.2) that uses --exclude to prevent traversing into treewalk() if the
> regexp is on the list. Thus if we specify "--exclude=.snapshot", that
> directory (regardless where) is completely skipped, as well as our
> quarantine area.

That's exactly what --exclude-dir does. (BTW: there was a bug in
--exclude-dir when it was used multiple times, now fixed in CVS)

> Don't understand why --exclude-dir is needed at all

The two options --exclude and --exclude-dir were seperated for safety
reasons. As you can see in the changelog, the first change was to use
--exclude both for files and directories. Unfortunately, using
--exclude in the both cases is not always safe because a too generic
regular expression for excluding some files could also block many
(Continue reading)

Bogusław Brandys | 16 Nov 15:06 2005
Picon

ClamLite


Hello,

Although I hadn't have spare time I prepare simple windows antivirus -
ClamLite based on libclamav.dll (which is used also by Clammail)

Check this : http://sourceforge.net/forum/forum.php?forum_id=511561
and
http://sourceforge.net/project/showfiles.php?group_id=125389&package_id=169589

Sources are included in ClamMail CVS.

Best regards
Boguslaw Brandys
Brian Bebeau | 16 Nov 22:41 2005
Picon

ClamAV infinite loop

In tracking down another problem when memory runs
out, I found an infinite loop.

In mbox.c, starting at line 1633.

for(multiparts = 0; t_line; multiparts++) {
                 int lines = 0;
                 message **m;

                 m = cli_realloc(messages, ((multiparts + 1) *
sizeof(message *)));
                 if(m == NULL)
                     break;
                 messages = m;

                 aMessage = messages[multiparts] = messageCreate();
                 if(aMessage == NULL) {
                     multiparts--;
                     continue;
                 }

cli_realloc() doesn't fail, so it never breaks out of the loop
from that. messageCreate(), which calls cli_calloc(), DOES fail,
so it decrements the part number and goes back to the for loop,
which increments the part number, which does the same thing it
just tried, with the same results, ad infinitum. What's supposed
to be accomplished by retrying after messageCreate()? Nothing gets
freed in the loop, so why try the calloc() again?

_______________________________________________
(Continue reading)

Yuri Dario | 17 Nov 23:43 2005

access violation in cli_bm_scanbuff

Hi,

I just recompiled ClamAV 0.87.1 under OS/2, and I discovered a file 
able to crash the function in the subject.

Debugging code, showed that at some point in cli_scandesc() 
(matcher.c) at line #292

	while((bytes=...)

only 21020 bytes are read from file. At this time length=98538, so at 
line 298 the result is -115514.
Then cli_bm_scanbuff() is called, but here the length parameter is 
declared as unsigned int instead of integer, so length became a very 
high value.

I don't understand if length should be negative or reset to zero, so 
I'm posting here.

The file is available on request.

TIA,

Yuri Dario

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html


Gmane