I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash: ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A variant of the race condition can also occur with `stub_NtMapViewOfSection` failing silently if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose an additional patch to fix it.
Bug 1850969 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A variant of the race condition can also occur with `stub_NtMapViewOfSection` failing silently if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose an additional patch to fix it.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A variant of the race condition can also occur with `stub_NtMapViewOfSection` failing silently if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose an additional patch to fix it.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A variant of the race condition can also occur with `stub_NtMapViewOfSection` failing if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose an additional patch to fix it.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A non-crashing variant of the race condition can also occur with `stub_NtMapViewOfSection` failing if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose an additional patch to fix it.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A non-crashing variant of the race condition can also occur with `stub_NtMapViewOfSection` failing if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose a patch to fix this.
I think the sequence of events below leads to the `NtQueryObject` failure and the follow-up crash: ``` MainThread | Third-Party Thread ---------- | ------------------ main() | | LoadLibrary("thirdparty.dll") | patched_NtMapViewOfSection() | stub_NtMapViewOfSection() | AfterMapViewOfExecutableSection() | SharedSection::GetKernel32Exports() | SharedSection::EnsureWriteCopyView() SharedSection::ConvertToReadOnly() | SharedSection::Reset() | RtlRunOnceInitialize(&sEnsureOnce) | | RtlRunOnceExecuteOnce(&sEnsureOnce) | SharedSection::EnsureWriteCopyViewOnce() | nt::AutoMappedView(sSectionHandle) | patched_NtMapViewOfSection(aSection) | stub_NtMapViewOfSection(aSection) CloseHandle(sSectionHandle); | | NtQueryObject(aSection) v ``` By forcing events to occur in this order with the attached patch (where I call `SharedSection::GetKernel32Exports` directly and not through `LoadLibrary`), I do get a very similar crash (note: this is before D187737): ``` 1:005> r rax=0000000000000005 rbx=0000000000000000 rcx=69b7c8805b380000 rdx=0000000000000000 rsi=00007ff6d3e646e8 rdi=000001fb889e0000 rip=00007ff6d3e1841f rsp=000000ccea1ffad0 rbp=00007ff6d3e18380 r8=0000000000000005 r9=0000000000000061 r10=0000000000000004 r11=00000000000002c0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 firefox!mozilla::freestanding::SharedSection::Layout::Resolve [inlined in firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f]: 00007ff6`d3e1841f 8b07 mov eax,dword ptr [rdi] ds:000001fb`889e0000=???????? 1:005> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::Layout::Resolve [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 303] 01 000000cc`ea1ffad0 00007ffb`1ed823ea firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyViewOnce+0x9f [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 285] 02 000000cc`ea1ffb50 00007ff6`d3e1670b ntdll!RtlRunOnceExecuteOnce+0x9a 03 (Inline Function) --------`-------- firefox!mozilla::freestanding::SharedSection::EnsureWriteCopyView+0x46 [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 291] 04 000000cc`ea1ffb90 00007ff6`d3e019a0 firefox!mozilla::freestanding::SharedSection::GetKernel32Exports+0x4b [C:\mozilla-source-alt\mozilla-unified\browser\app\winlauncher\freestanding\SharedSection.cpp @ 365] 05 000000cc`ea1ffbc0 00007ffb`1cd3257d firefox!RacyThreadFunc+0x10 [C:\mozilla-source-alt\mozilla-unified\browser\app\nsBrowserApp.cpp @ 278] 06 000000cc`ea1ffbf0 00007ffa`c50576d4 KERNEL32!BaseThreadInitThunk+0x1d 07 (Inline Function) --------`-------- mozglue!mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mozilla::interceptor::VMSharingPolicyShared>,void (*)(int, void *, void *)>::operator()+0x15 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\nsWindowsDllInterceptor.h @ 150] 08 000000cc`ea1ffc20 00007ffb`1edaaa68 mozglue!patched_BaseThreadInitThunk+0x94 [C:\mozilla-source-alt\mozilla-unified\toolkit\xre\dllservices\mozglue\WindowsDllBlocklist.cpp @ 566] 09 000000cc`ea1ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ``` A non-crashing variant of the race condition can also occur with `stub_NtMapViewOfSection` failing if it received the handle that was just closed on the main thread by `SharedSection::Reset`. This variant was present before bug 1842088 and is still present today. I think the consequence could be that we would silently fail to load and use the blocklist? I will propose a patch to fix this.