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

[Glen Barber]

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

> 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.

> 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)).
> 

Thanks and regards,

-- 
Glen Barber