chore: cherry-pick fefd6198da31 from chromium #35883
Merged
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.
[M106] Fix races in FrameQueueUnderlyingSource related to CrossThreadPersistent
The repro in bug 1323488 unfortunately does not reliably reproduce
the races when run as a web test. I was also not able to repro the
races in a unit test.
There are actually three fixes in this CL; it was easiest to fix them
all together so that I can run the repro locally for an extended period
without it being stopped by a crash.
The underlying cause for all three races is that CrossThreadPersistent
can refer to an object whose heap has already been destroyed. When
accessed on the thread corresponding to that heap, there is no race,
but when accessed from a different thread, there is a period of time
after the heap is destroyed before the CrossThreadPersistent is
cleared.
The FrameQueueUnderlyingSource::transferred_source_ member's pointer
is accessed in FrameQueueUnderlyingSource::Close. This CL adds a
callback to clear the pointer in
TransferredFrameQueueUnderlyingSource::ContextDestroyed.
The TransferredFrameQueueUnderlyingSource constructor takes a raw
pointer to the original FrameQueueUnderlyingSource, which is
associated with a different thread. GC won't be able to update this
raw pointer since it's on the wrong stack. This CL changes the raw
pointer to a CrossThreadPersistent which is visible to GC.
Same as 2, but for the callstack ConnectHostCallback,
MediaStream(Audio|Video)TrackUnderlyingSource::OnSourceTransferStarted
and FrameQueueUnderlyingSource::TransferSource.
(cherry picked from commit 63ce9c40e1a67395278dfc70ecfb545a818747bb)
Bug: 1323488
Change-Id: Id63484eebefd2e003959b25bd752ac8263caab4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3865452
Commit-Queue: Ben Wagner benjaminwagner@google.com
Reviewed-by: Thomas Guilbert tguilbert@chromium.org
Auto-Submit: Ben Wagner benjaminwagner@google.com
Cr-Original-Commit-Position: refs/heads/main@{#1041434}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3908010
Commit-Queue: Srinivas Sista srinivassista@chromium.org
Reviewed-by: Srinivas Sista srinivassista@chromium.org
Cr-Commit-Position: refs/branch-heads/5249@{#521}
Cr-Branched-From: 4f7bea5de862aaa52e6bde5920755a9ef9db120b-refs/heads/main@{#1036826}
Ref electron/security#222
Notes: Security: backported fix for CVE-2022-3307.