Bug 2380 - clamd 0.96.4 damon segfaults on some pdf
clamd 0.96.4 damon segfaults on some pdf
Status: RESOLVED FIXED
Product: ClamAV
Classification: ClamAV
Component: clamd
stable
x86_64 GNU/Linux
: P3 security
: 0.96.5
Assigned To: Török Edwin
: havepatch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-15 06:56 EST by Arkadiusz Miskiewicz
Modified: 2018-07-11 15:51 EDT (History)
3 users (show)

See Also:
QA Contact:


Attachments
patch with changelog (1.21 KB, patch)
2010-11-15 16:53 EST, Török Edwin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arkadiusz Miskiewicz 2010-11-15 06:56:20 EST
q = pdf_nextobject(pdf->map+obj->start, pdf->size - obj->start);

returns NULL and clamd doesn't check that. Segfaults on my busy server once per 1-2 hours (likely remote server is retrying delivery of the message with problematic pdf (which I don't have))

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f7a262bc710 (LWP 2771)]
0x00007f7a37c75bb5 in ?? () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f7a37c75bb5 in ?? () from /lib64/libc.so.6
#1  0x00007f7a37c72f20 in atoi () from /lib64/libc.so.6
#2  0x00007f7a382d7116 in find_length (pdf=0x7f7a262b4b40, obj=0x7f7a2026a78c,
    start=0x7f7a390f6516 "27 0 R >> \rstream\r\nH\211T\226˵\244+\bF\347\025EE\340R@\304\070n\032\247\363\237^^*5굛\257x\313\177>S\270u\370\002Q\003\370\376}\246\314\066\202;9\217&\360\035K\332\340ᅬ\351\027\035\016\375\022\345", <incomplete sequence \355>, len=26) at pdf.c:471
#3  0x00007f7a382d776a in pdf_extract_obj (pdf=0x7f7a262b4b40, obj=0x7f7a2026a600) at pdf.c:594
#4  0x00007f7a382d935e in cli_pdf (dir=0x7f7a20000cd0 "/tmp/clamav-e0c6adb00400288fc73782659b44432a", ctx=0x7f7a262b99b0, offset=0) at pdf.c:1115
#5  0x00007f7a382771a4 in cli_scanpdf (ctx=0x7f7a262b99b0, offset=0) at scanners.c:1465
#6  0x00007f7a3827ac9a in magic_scandesc (desc=16, ctx=0x7f7a262b99b0, type=CL_TYPE_PDF) at scanners.c:2256
#7  0x00007f7a3827b980 in cli_magic_scandesc (desc=16, ctx=0x7f7a262b99b0) at scanners.c:2385
#8  0x00007f7a382fcae0 in cli_7unz (fd=14, ctx=0x7f7a262b99b0) at 7z.c:122
#9  0x00007f7a3827a84e in magic_scandesc (desc=14, ctx=0x7f7a262b99b0, type=CL_TYPE_7Z) at scanners.c:2187
#10 0x00007f7a3827b980 in cli_magic_scandesc (desc=14, ctx=0x7f7a262b99b0) at scanners.c:2385
#11 0x00007f7a3827fb0b in fileblobScan (fb=0x7f7a20282560) at blob.c:644
#12 0x00007f7a3827f2bd in fileblobScanAndDestroy (fb=0x7f7a20282560) at blob.c:405
#13 0x00007f7a382862d1 in do_multipart (mainMessage=0x7f7a20269ba0, messages=0x7f7a20001350, i=0, rc=0x7f7a262b9224, mctx=0x7f7a262b9370,
    messageIn=0x7f7a20269ba0, tptr=0x7f7a262b9218, recursion_level=0) at mbox.c:3622
#14 0x00007f7a38281f32 in parseEmailBody (messageIn=0x7f7a20269ba0, textIn=0x0, mctx=0x7f7a262b9370, recursion_level=0) at mbox.c:1533
#15 0x00007f7a38280220 in cli_parse_mbox (dir=0x7f7a20000c90 "/tmp/clamav-87c959bf6408b84103c7c77e08848693", desc=13, ctx=0x7f7a262b99b0) at mbox.c:511
#16 0x00007f7a3827fc66 in cli_mbox (dir=0x7f7a20000c90 "/tmp/clamav-87c959bf6408b84103c7c77e08848693", desc=13, ctx=0x7f7a262b99b0) at mbox.c:311
#17 0x00007f7a3827748b in cli_scanmail (desc=13, ctx=0x7f7a262b99b0) at scanners.c:1547
#18 0x00007f7a3827a685 in magic_scandesc (desc=13, ctx=0x7f7a262b99b0, type=CL_TYPE_MAIL) at scanners.c:2156
#19 0x00007f7a3827b980 in cli_magic_scandesc (desc=13, ctx=0x7f7a262b99b0) at scanners.c:2385
#20 0x00007f7a3827bad6 in cli_scandesc_stats (desc=13, virname=0x7f7a262bbb00, virhash=0x7f7a262b9ab0 "", virsize=0x7f7a262bbb08, scanned=0x0,
    engine=0x90ae00, scanoptions=25143) at scanners.c:2435
#21 0x0000000000411ff1 in scanstream (odesc=10, scanned=0x0, engine=0x90ae00, options=25143, opts=0x633c80, term=10 '\n') at scanner.c:465
#22 0x000000000040ab2a in command (conn=0xbe5780, virus=0x7f7a262bbdcc) at session.c:326
#23 0x000000000040d758 in scanner_thread (arg=0xbe5780) at server-th.c:100
#24 0x000000000040ceaa in thrmgr_worker (arg=0x8eb600) at thrmgr.c:653
#25 0x00007f7a37fb4da5 in start_thread () from /lib64/libpthread.so.0
#26 0x00007f7a37d12f3d in clone () from /lib64/libc.so.6
#27 0x0000000000000000 in ?? ()
(gdb) frame 2
#2  0x00007f7a382d7116 in find_length (pdf=0x7f7a262b4b40, obj=0x7f7a2026a78c,
    start=0x7f7a390f6516 "27 0 R >> \rstream\r\nH\211T\226˵\244+\bF\347\025EE\340R@\304\070n\032\247\363\237^^*5굛\257x\313\177>S\270u\370\002Q\003\370\376}\246\314\066\202;9\217&\360\035K\332\340ᅬ\351\027\035\016\375\022\345", <incomplete sequence \355>, len=26) at pdf.c:471
471     pdf.c: Nie ma takiego pliku ani katalogu.
        in pdf.c
(gdb) print q
$1 = 0x0


   469              }
   470              q = pdf_nextobject(pdf->map+obj->start, pdf->size - obj->start);
   471              length = atoi(q);
   472          }
   473      }
Comment 2 Török Edwin 2010-11-15 16:53:35 EST
Created attachment 1588 [details]
patch with changelog

Same as original patch + ChangeLog entry.
Comment 3 Török Edwin 2010-11-15 16:54:44 EST
(In reply to comment #2)
> Created an attachment (id=1588) [details]
> patch with changelog
> 
> Same as original patch + ChangeLog entry.

I've added a changelog entry to your patch.

Tomasz, this is patch for 0.97.
Comment 4 Tomasz Kojm 2010-11-15 17:21:08 EST
Can we temporarily work around the problem with bytecode?
Comment 5 Török Edwin 2010-11-15 21:30:57 EST
Pubished bytecode version 91.

Arkadiusz, can you update to latest bytecode by running freshclam, and confirm that clamd does not crash, *without* the patch?

The bytecode is supposed to stop the scan when it would otherwise crash.