Clam freezes during recursive scan

[rgolodner]

Binary package hint: clamav

As you can see from the screenshot there is pread fail during a recursive scan of my machine.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: clamav 0.96.1+dfsg-0ubuntu0.10.04.1
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Wed Jun 23 16:38:42 2010
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: clamav

[Scott Kitterman (kitterman)]

No screen shot attached.

[rgolodner (rgolodner)]

On Wed, 2010-06-23 at 23:46 +0000, Scott Kitterman wrote:
> No screen shot attached.
 Hi Scott, I did attach a screenshot to the original case and thought I
had done so when prompted the second time via the bug tracker. Perhaps
this will help.
 Most sincerely, Richard Golodner

[Scott Kitterman (kitterman)]

What is the exact command you used to run clamav?

[rgolodner (rgolodner)]

On Thu, 2010-06-24 at 02:44 +0000, Scott Kitterman wrote:
> What is the exact command you used to run clamav?
 Scott, please frogive my newness as I am a Cisco guy tired of Windows
and wanted to try an alternate O/S.
 The exact command I use was one I had seen on a Ubuntu forum and it is:
$ clamscan -r /
 Thank you for any help you may provide.
 Most sincerely, Richard

[Scott Kitterman (kitterman)]

I can't replicate the problem here. Let me see if I can get someone else to have a look.

[Steve Beattie (sbeattie)]

I can reproduce the pread() failures with clamscan from clamav 0.96.1+dfsg-0ubuntu0.10.04.1 on lucid; however, all of the files reporting errors occur on /sys which is the (default) location where the sysfs filesystem is located. The sysfs filesystem is a synthetic filesystem that exposes information about the system: buses, devices, cpus, etc. As I said, it's a synthetic filesystem; that is, the contents of the directories and files are generated by the kernel on the fly and in many cases the amount of data reported may not be easily computable in advance.

Thus, if you examine the files that clamscan is reporting errors about, you'll see that they're usually 4096 bytes in size, and clamscan is failing to read X number of bytes after having read 4096 - X bytes from the file.

For the speculators, I've also verified by examining /var/log/kern.log that these pread() failures are not the result of AppArmor rejections.

On my test system, I also reproduce the apparent hanging behavior, it's stuck repeatedly trying to pread() from /sys/devices/platform/vga16fb.0/graphics/fb0/bl_curve and not stopping despite getting EINVAL returned, as the snippet from ptrace shows:

  pread(10, 0x7fd093dd6550, 14189025968, 18446744059520529744) = -1 EINVAL (Invalid argument)
  pread(10, 0x7fd093dd654f, 14189025969, 18446744059520529743) = -1 EINVAL (Invalid argument)
  pread(10, 0x7fd093dd654e, 14189025970, 18446744059520529742) = -1 EINVAL (Invalid argument)

 $ sudo ls -l /proc/15345/fd/10
  lr-x------ 1 root root 64 2010-06-23 23:37 /proc/15345/fd/10 -> /sys/devices/platform/vga16fb.0/graphics/fb0/bl_curve

Really, clamscan should be skipping sysfs filesystems; if your running kernel is offering up trojaned or otherwise malicious files there, your system is seriously compromised and whatever has been maliciously injected into it would likely also be smart enough to behave normally for something that looks like a virus/trojan scanner. OTOH, it could be more sensible about how it behaves in the face of files that lie about its size.

I've attached the output from my test run of clamscan, to show that indeed, all the files I saw reported are under /sys aka sysfs.

[dino99 (9d9)]

This version has expired