It was discovered, that OpenOffice.org memory allocator is not 64bit clean.
rtl_allocateMemory() function in sal/rtl/source/alloc_global.c accepts one
argument - sal_Size n.  On 64bit platforms such as x86_64, sal_Size is defined
as unsigned long int.  This requested memory chunk size is later memory aligned
as size (type sal_Size).  size is later used to calculate int index to
g_alloc_table[] array:

  int index = (size - 1) >> RTL_MEMALIGN_SHIFT;

However, as sizeof(int) == 4 and sizeof(sal_Size) == 8 on 64bit platforms, the
calculated value may not fit into index (this can happen when
rtl_allocateMemory() is called with large argument, e.g. when some other flaw
causes OpenOffice to attempt to allocate chunk of memory with negative size,
which wraps to large positive value during signed -> unsigned type conversion,
such as [1]).  Value stored in the index is wrapped / truncated, possibly
resulting in the index being negative.

Before index is used, it is checked not to exceed fixed upper limit, but it's
not checked whether its value is >= 0:

  if (index < RTL_MEMORY_CACHED_LIMIT >> RTL_MEMALIGN_SHIFT)

Negative index used in g_alloc_table[index] will cause OpenOffice to access
memory outside of the g_alloc_table[] array.  This may result it crash, or if
that points to an attacker controlled memory, attacker may possibly be able to
use this flaw to run arbitrary code.

[1] http://www.openoffice.org/issues/show_bug.cgi?id=91818
    http://scary.beasts.org/security/CESA-2008-006.html