Fix TOCTOU race in AppDomain::LoadAssembly fast-path#125408
Merged
AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom Mar 11, 2026
Merged
Fix TOCTOU race in AppDomain::LoadAssembly fast-path#125408AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom
AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom
Conversation
PR dotnet#120515 deferred Assembly creation (lazy init), making FileLoadLock::m_pAssembly mutable. The fast-path in LoadAssembly cached pAssembly before checking GetLoadLevel(), so a thread could read nullptr, get preempted while another thread completed the load, then pass the level check and dereference the stale nullptr. Re-read pAssembly from the FileLoadLock inside the fast-path block after the level check passes, ensuring we use the pointer that corresponds to the observed load level. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Tagging subscribers to this area: @agocke, @elinor-fung |
Member
Author
|
This will need to be ported back to .NET 10 as well. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a TOCTOU race in the AppDomain::LoadAssembly fast-path that could dereference a stale nullptr Assembly* when another thread finishes populating FileLoadLock::m_pAssembly between separate reads of the assembly pointer and the lock’s load level.
Changes:
- Moves the
pLock->GetAssembly()read inside the “already loaded” fast-path block, after confirmingGetLoadLevel() >= targetLevel. - Re-reads
pAssemblyfrom the lock at the end of the slow-path using a fresh local declaration (no longer depending on an outer-scoped cached pointer).
Member
Author
|
/backport to release/10.0 |
Contributor
|
Started backporting to |
4 tasks
agocke
approved these changes
Mar 11, 2026
JulieLeeMSFT
pushed a commit
that referenced
this pull request
Mar 11, 2026
…125424) Backport of #125408 to release/10.0 /cc @AaronRobinsonMSFT ## Customer Impact - [x] Customer reported - [ ] Found internally The reproduction rate in a real application environment is extremely low (< 1/100,000) as it requires simultaneous EOF on stdout/stderr, an unloaded target assembly, and exact OS thread preemption. This is a reliability issue tht impacted a high value enterprise customer and can impact other users. ## Regression - [x] Yes - [ ] No Yes in PR #120515. ## Testing The change here is an obvious TOCTOU issue. The source was updated in a clearer way to avoid creating locals that are populated long before use. ## Risk Low. The source change is narrowing the use of a local behind a lock in a manner that is more local to use. This reflects better engineering practices and can easily be audited for correctness. Co-authored-by: Aaron R Robinson <arobins@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR #120515 deferred Assembly object creation to fix duplicate ICorProfiler callbacks, making
FileLoadLock::m_pAssemblystart asnullptrand get populated lazily by the winning thread. However, the fast-path inAppDomain::LoadAssemblywas not updated to account for this mutability.The Bug
The fast-path cached
pAssembly = pLock->GetAssembly()(readingnullptr) before checkingpLock->GetLoadLevel() >= targetLevel. If another thread completed the load between these two reads, the level check would pass but the code would dereference the stalenullptr, causing an Access Violation (0xC0000005) insideAssembly::ThrowIfError.This is a classic TOCTOU (Time-of-Check to Time-of-Use) race. It was reported as a rare fatal crash (< 1/100,000) under heavy CPU load when lazy-loaded assemblies (e.g.,
System.Threading.ThreadPool) are resolved concurrently on multiple threadpool threads.The Fix
Move the
GetAssembly()read inside the fast-pathifblock, after confirming the load level is sufficient. This mirrors the pattern already used at the end of the slow path (line 2619), wherepAssemblyis re-read from the lock before use.