BugZero found this defect 33 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
4/16/2024
MongoDB Server
No affected releases provided.
No fixed releases provided.
MozJSImplScope::ASANHandles is used to track the addresses of allocations within mozjs. Prior to the ESR115 upgrade, the implementation was done in a thread local fashion, with each thread getting its own ASANHandles tracker. After the ESR115 upgrade, the implementation had to be changed to a global singleton shared by all threads. This introduces additional complexity, as contending threads could be modifying the internal address map simultaneously. Whenever an allocation (or deallocation) takes place within mozjs, the corresponding allocated/freed address is added or removed from the map within ASANHandles. The map within ASANHandles is guarded by a lock, however, since the allocate/free operation is not under the same lock, it is possible that we could find ourselves in a situation where one thread still has to remove its pointer from the map (but the memory has already been freed), while a separate thread has received the same address during an allocation, and is inserting into the map. BF-32781 detects this exact scenario. As a quick fix, we choose to relax the invariant in ASANHandles::addPointer/removePointer, since this code was originally implemented when ASANHandles adhered to a thread local model. As an alternative, ASANHandles could be refactored to ensure allocations are performed under the same lock as the address map, but it is out of the scope of this ticket. Given that this code is only active in ASAN builds, we would like to minimize any significant impact on the release builds. It is important to note that this code does not affect any runtime logic or behaviour, it is in place to appease the ASAN build by keeping the addresses in memory.