In #7114, there's logic to create and initialize a module_mapper_t object (initialization happens by calling get_loaded_modules which uses read_and_map_modules1) in a worker thread during drmemtrace analysis. Such use of module_mapper_t during trace analysis seems new, because in existing module_mapper_t uses (in opcode_mix and view), the module_mapper_t is initialized in the main thread (in initialize and initialize_stream analysis tool APIs). This revealed an existing issue in the implementation of elf_loader_map_phdrs2 which is used by dr_map_executable_file to map the modules into the process address space.

There seems to be an implicit assumption in module_mapper_t that the app is reasonably quiesced when read_and_map_modules is invoked.

There's a race between the thread initializing the module mapper and other threads that may also be doing their mmaps (from non module mapper code) at the same time. elf_loader_map_phdrs first obtains an anonymous map, and then for each loadable segment, it "momentarily"3 unmaps some part of the anonymous map and maps the loadable segment to it using MAP_FIXED. The issue arises when (also as noted by the comment above 3) another thread mmaps some overlapping addresses between the unmap-map events; since we use MAP_FIXED4 we would end up stealing those regions from the other threads without them realizing. When the other threads finish, they would very likely want to unmap what they previously mapped, which would actually unmap some part of our mapped binaries, causing a fault if the module_mapper_t tries reading those addresses.