security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host

Jeremy Chadwick freebsd at
Fri Aug 27 18:20:32 UTC 2010

On Fri, Aug 27, 2010 at 01:58:25PM -0400, Glen Barber wrote:
> On 8/27/10 1:32 PM, Jeremy Chadwick wrote:
> >> Of course.  The new backtrace is here:
> > 
> > I want to make sure I understand the environment -- on a native i386
> > (32-bit) FreeBSD host, the software works fine.  But on a native amd64
> > (64-bit) FreeBSD host, the software segfaults.  Correct?
> > 
> The clamav instance runs on a 64-bit host in a 32-bit jail.  In a 32-bit
> host/32-bit jail environment, the software runs fine, as you suggest above.
> > If so -- it appears as if the system you're providing the backtrace from
> > is a 32-bit system, or within a 32-bit environment?  I would expect to
> > see 64-bit addresses in the backtrace, yet they're all 32-bit.
> > 
> > I'm not familiar with jailed environments (or the concept/possibility of
> > running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit
> > jails)).  I don't use lib32 on my amd64 systems.
> > 
> To be honest, this is the first non-base software I've had an issue with
> in a mixed-arch environment.

Okay, so it's sort of what I thought.  Your system has a series of
include files on it that are for amd64 (64-bit), but clamav, when built
within a 32-bit jail on that system, is (probably -- no proof, but it's
an educated guess based on what's happening) detecting some 64-bit
pieces through include files and making some incorrect assumptions about
the size of some types.

I'd really need to set up a testbed system/VM and get full instructions
from start to finish on how to set up a 32-bit jail and so on, given
that I've never done it.  Otherwise, you're probably going to need to
find someone who has a similar setup and can reproduce the problem, or
give a developer root-level access to your system.

> > I did take a look at the clamav code itself (I'd have to spend a few
> > hundred lines outlining it here and would rather not).  My guess is that
> > there's a conflict between what the running OS architecture is and what
> > the build process determines the architecture is.
> > 
> > Given that you have jails, and possibly a mixed architecture environment
> > on a single host (e.g. 64-bit host OS with 32-bit jails), can you
> > explain exactly how you go about building clamav, followed by how you go
> > about running it?
> The build is done from ports with no special options excluding the
> latest build, being:
> The only make.conf entry is PERL_VERSION=5.10.1.
> The clamd service runs under djb's supervise (/usr/local/sbin/clamd).
> Additionally, port builds were done after setting UNAME_m and UNAME_p
> [1], but I haven't had luck with that overriding the machine hardware type.
> If this provides any clues, here's what file(1) sees, as well as ldd:
> % file /usr/local/sbin/clamd
> /usr/local/sbin/clamd: ELF 32-bit LSB executable, Intel 80386, version 1
> (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not
> stripped
> % ldd /usr/local/sbin/clamd
> /usr/local/sbin/clamd:
> => /usr/local/lib/ (0x280ac000)
> => /lib/ (0x281f8000)
> => /usr/lib/ (0x2820a000)
> => /lib/ (0x2821b000)
> => /lib/ (0x28235000)
> => /lib/ (0x2824a000)
> [1] -

Right -- I understand the binary is 32-bit, but that's not where the
problem lies (based on my guess).  The binary obviously runs, or else
you wouldn't be seeing a segfault or even get a remotely coherent
backtrace in gdb.

I'm not sure how to explain this in a way that's easily understandable
(I'm assuming you're not a programmer.  :-) ).  My guess is that during
compile-time, the compiler is kicking out some code that's based on
sizeof(int) == 8 (64-bit), when that shouldn't be the case in a 32-bit
environment.  Include files could cause this problem too.

There may be some "black magic" in the ports infrastructure (maybe even
on a per-port basis) to work around this problem that the clamav port
isn't making use of.  I really don't know.

Sorry I can't be of more help.  I'm one of those guys who if he needs a
32-bit and 64-bit system, buys two physical systems.

| Jeremy Chadwick                                   jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-ports mailing list