FuncHookCrossProcess should not store the child process's stub function in mOrigFunc
Categories
(Core :: mozglue, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: bugzilla, Assigned: bugzilla)
References
Details
Attachments
(1 file)
This is showing up with hooks that are set both by the launcher process and by the browser process when starting early DLL blocklist init on content processes:
- The browser's copy of
mOrigFuncwas set by the launcher process. - The browser is setting a hook in the new child process, which writes to the child's
mOrigFunc. - But
FuncHookCrossProcessalso writes that pointer to the browser'smOrigFunc, thus corrupting the browser process's copy of the pointer.
For in-process hooks, we want to immediately write the stub pointer to its final location; this is not an issue for cross-process hooks since the child process is suspended when we do this and the parent process can't call the stub; there is no possibility of a race.
|
Assignee | |
Comment 1•5 years ago
|
||
This is showing up with hooks that are set both by the launcher process and by
the browser process when starting early DLL blocklist init on content processes:
- The browser's copy of mOrigFunc was set by the launcher process.
- The browser is setting a hook in the new child process, which writes to the
child's mOrigFunc. - But FuncHookCrossProcess also writes that pointer to the browser's mOrigFunc,
thus corrupting the browser process's copy of the pointer.
For in-process hooks, we want to immediately write the stub pointer to its final
location; this is not an issue for cross-process hooks since the child process
is suspended when we do this and the parent process can't call the stub; there
is no possibility of a race.
Pushed by aklotz@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/de034010ab47 Change cross-process stub to not store remote stub pointer in local mOrigFunc; r=handyman
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•