Bug ID: 115399
           Summary: Data race in typelib_typedescription_register
           Product: LibreOffice
           Version: release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: sdk

cppu/source/typelibtypelib.cxx, typelib_typedescription_register contains a
data race that might cause crashes.

In short: typelib_typedescription_register replaces members of already stored
type descriptions without synchronizing with other threads that might currently
use those members.

Crash scenario is as follows:
* thread A is processing an IPC call involving an out parameter with struct
type (the type description for this struct's bComplete member is 0 up to now)
** thread A is copying the C++ out parameter to the BinaryAny objects for
transferring it via IPC, and calls _copyConstructStruct (copy.hxx)
** _copyConstructStruct copies member per member, using the type description's
pMemberOffsets and ppTypeRefs member attributes

* at the same time thread B also needs this struct type for its work, and tries
to complete the struct type description (complete(...) in typelib.cxx).
** after completing the type description, the completed description is
registered via typelib_typedescription_register
** typelib_typedescription_register notices that the new description is
complete, but the previously stored was not -> it calls
typelib_typedescription_destructExtendedMembers(...) on the old, stored
** typelib_typedescription_destructExtendedMembers(...) deletes the memory used
for the pMemberOffsets and ppTypeRefs members (while they are in use by thread
** typelib_typedescription_register replaces the members in the stored struct
with those from the new struct

Depending on the timing, thread A accesses already freed memory (no crash), or
sees already different data at the pMemberOffset/ppTypeRefs pointers. The
latter case happened for me, pMemberOffsets[0] was 0 and pMemberOffsets[1] was
0, ie. have already been reused for something else.
My struct contained a long and a type member, and the code crashed since it
wanted to copy the type member at offset 0, which contained a 1 -> access to
memory 0x1 instead of just copying the 1 as long value.

The issue seems to be present in libreoffice (at least from looking at
the typelib code), I found the issue in libreoffice

You are receiving this mail because:
You are the assignee for the bug.
Libreoffice-bugs mailing list

Reply via email to