https://bugs.documentfoundation.org/show_bug.cgi?id=115399
Bug ID: 115399
Summary: Data race in typelib_typedescription_register
Product: LibreOffice
Version: 4.1.4.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: sdk
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: str...@sb-software.de
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
typedescription
** typelib_typedescription_destructExtendedMembers(...) deletes the memory used
for the pMemberOffsets and ppTypeRefs members (while they are in use by thread
A)
** 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 6.0.0.3 (at least from looking at
the typelib code), I found the issue in libreoffice 4.1.4.2
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
