The previous attempt at avoiding the crash from bug 1733532 resulted in breaking DLL blocklist code on older versions of Windows, in particular Windows 7, which led to a crash spike (see bug 1837242). The detect executable DLL mappings, we must not look at the protection asked in the arguments of NtMapViewOfSection, but rather at the protection that was used to create the section. We already do this through NtQueryVirtualMemory, but in a helper function rather than directly in patched_NtMapViewOfSection. Because the helper function does not have MOZ_NO_STACK_PROTECTOR, it does not avoid stack cookie checks when NtMapViewOfSection is called from Thread32Next. To mitigate the crash from bug 1733532, we need to move the call to NtQueryVirtualMemory to the main patched function, at the (reasonable) cost of losing the stack cookie check on local variable mbi since this function has MOZ_NO_STACK_PROTECTOR.
Bug 1733532 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The previous attempt at avoiding the crash from bug 1733532 resulted in breaking DLL blocklist code on older versions of Windows, in particular Windows 7, which led to a crash spike (see bug 1837242). To detect executable DLL mappings, we must not look at the protection asked in the arguments of NtMapViewOfSection, but rather at the protection that was used to create the section. We already do this through NtQueryVirtualMemory, but in a helper function rather than directly in patched_NtMapViewOfSection. Because the helper function does not have MOZ_NO_STACK_PROTECTOR, it does not avoid stack cookie checks when NtMapViewOfSection is called from Thread32Next. To mitigate the crash from bug 1733532, we need to move the call to NtQueryVirtualMemory to the main patched function, at the (reasonable) cost of losing the stack cookie check on local variable mbi since this function has MOZ_NO_STACK_PROTECTOR.