Bug ID: 115399
Summary: Data race in typelib_typedescription_register
Version: 22.214.171.124 release
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 was 0 and pMemberOffsets 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 126.96.36.199 (at least from looking at
the typelib code), I found the issue in libreoffice 188.8.131.52
You are receiving this mail because:
You are the assignee for the bug.
Libreoffice-bugs mailing list