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.