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

[Jeremy Chadwick]

On Fri, Aug 27, 2010 at 09:58:38PM +0300, Kostik Belousov wrote:
> On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote:
> > On 8/27/10 12:54 PM, Jeremy Chadwick wrote:
> > > On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote:
> > >> On 8/27/10 12:33 PM, Kurt Jaeger wrote:
> > >>> Hi!
> > >>>
> > >>>> I have a few clamav instances running in jails on 32-bit hosts without
> > >>>> any issues.  A few days ago one of these jails was migrated to a 64-bit
> > >>>> host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried.
> > >>>>
> > >>>> The issue seems specific to 32bit/64bit compatibility.  I have a gdb
> > >>>> session available here: http://gist.github.com/549964
> > >>>>
> > >>>> Any thoughts on if this is possible?
> > >>>
> > >>> Try
> > >>>
> > >>> Bytecode no
> > >>>
> > >>> in clamd.conf ?
> > >>>
> > >>
> > >> It was set to 'yes' initially.  I thought it was disabled with building
> > >> without JIT.  At any rate, no, it still segfaults with the same backtrace.
> > > 
> > > 1) Is clamd built with debugging symbols enabled?  If not, you might want
> > > to rebuild it with such, else it might be difficult to debug the
> > > problem.
> > > 
> > 
> > It wasn't initially, but is now.
> > 
> > > Also, if the segfault happens after performing the above, can you
> > > provide output from "bt full" instead of just "bt"?
> > > 
> > 
> > Of course.  The new backtrace is here: http://gist.github.com/553734
> I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8.

Would that be these two?

http://svn.freebsd.org/viewvc/base?view=revision&revision=210796
http://svn.freebsd.org/viewvc/base/head/sys/compat/freebsd32/freebsd32_misc.c?r1=210796&r2=210795&pathrev=210796
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.110;r2=1.111;f=h

http://svn.freebsd.org/viewvc/base?view=revision&revision=211138
http://svn.freebsd.org/viewvc/base/stable/8/sys/compat/freebsd32/freebsd32_misc.c?r1=211138&r2=211137&pathrev=211138
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.93.2.13;r2=1.93.2.14;f=h

Based on this PR?

http://www.freebsd.org/cgi/query-pr.cgi?pr=149227

> > > 2) Was the software rebuilt from source after the upgrade from i386 to
> > > amd64, or are you expecting the software to work without any hitches
> > > running on amd64 with lib32 (32-bit compatibility libaries)?  The latter
> > > is not always possible/the case.
> > > 
> > 
> > clamav was rebuilt from ports.  I previously went as far as downgrading
> > to the previous version, to rule out something between 0.96.1 and
> > 0.96.2; same results there.
> Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows
> 32-bit image being executed.
> 
> > 
> > > I have no familiarity with the software or functions in question, but an
> > > initial guess would be that some piece of the code is making assumptions
> > > about the size of pointers (expecting 4 (32-bit) rather than 8
> > > (64-bit)).  Speculative on my part, but I ponder such when seeing code
> > > like somefunc(sizeof(int)).
> Absolute nonsense.

Well, it's not really nonsense, but I'd rather not go to great lengths
to show how it's possible.  In this specific case it would end up
depending on what CMSG_LEN() does.  clamav does have some code where
CMSG_LEN() can get overridden (supposedly for Solaris 8 only).  This is
why I said I'd rather not post hundreds of lines of code; it's one of
those situations that's demonstrated when debugged in real-time and not
entirely by source analysis.

Anyway, as I said, I don't have familiarity with environments where
32-bit code is being run on 64-bit archs.

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