ClientSource::SetController crash with iframe
Categories
(Core :: DOM: Service Workers, defect, P2)
Tracking
()
People
(Reporter: 711924474as, Assigned: asuth)
References
Details
Crash Data
Attachments
(3 files, 1 obsolete file)
Screenshot from 2024-02-13 01-26-32.png
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0
Steps to reproduce:
Hello team:
I've been searching for errors in ""
But there was a problem that crashed the URL of the site you were on when Firefox crashed
Here are the steps:
I ran the following file poc.html as in the picture
<html>
<head>
<title>hacker</title>
</head>
<body>
<title>hacker</title>
<h1>hacker</h1>
<script>
function submitForm(){
document.forms[0].submit();}
</script>
<iframe src="https://www.marriott.com/sign-in.mi" onload="submitForm()" width="500" height="500"></iframe>
</form>
</body>
</html>
Actual results:
The malfunction occurred as in the following picture
|
Reporter | |
Comment 1•8 months ago
|
||
|
||
Comment 2•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•8 months ago
|
||
Can confirm.
I got a crash from user's testcase: https://crash-stats.mozilla.org/report/index/d532050f-c391-4e8e-a36d-fefce0240213#tab-bugzilla
|
|
||
Comment 4•8 months ago
|
||
|
|
||
Updated•8 months ago
|
|
||
Comment 5•8 months ago
|
||
Mayank, can you confirm that you are running your POC as a "file://" URL like the reporter seems to do from the screenshot?
|
|
||
Comment 6•8 months ago
•
|
||
Yes, just realized that you need to download the POC to your local machine, and then run it in Nightly.
Directly running the attachment from bugzilla doesnt repro.
You may also need to open the devtools (F12) and/or reload the page once.
|
|
||
Comment 7•8 months ago
|
||
This is the regression range i came up with :
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=74604ee44d4fd6f74574237076704e2febac6ae2&tochange=e0683c733cf9569c6fde4f57852efbb2befc8740
|
|
||
Comment 8•8 months ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 content process crashes on beta
For more information, please visit BugBot documentation.
|
Assignee | |
Comment 9•8 months ago
|
||
Thank you so much for the reproduction and the reproduction verification!
|
|
Assignee | |
Comment 10•8 months ago
|
||
(In reply to Mayank Bansal from comment #7)
This is the regression range i came up with :
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=74604ee44d4fd6f74574237076704e2febac6ae2&tochange=e0683c733cf9569c6fde4f57852efbb2befc8740
Oh goodness, and a bisection too! Thank you!
|
|
Assignee | |
Comment 11•8 months ago
|
||
Okay, pernosco trace with my gdb pretty printing trace inclusion quasi-fix so that after we do python import gdbpp in the python session we can more easily see[1] that in the failing call to ClientMatchPrincipalInfo aLeft has an mPartitionKey of "" and aRight has an mPartitionKey of "(file,)".
More verbosely:
(pernosco) p *((ContentPrincipalInfo*)&aLeft.mValue.VContentPrincipalInfo.u.mBytes)
$2 = {
attrs_ = {
<mozilla::dom::OriginAttributesDictionary> = {
<mozilla::dom::DictionaryBase> = {
mIsAnyMemberPresent = true
},
members of mozilla::dom::OriginAttributesDictionary:
mFirstPartyDomain = <gNullChar> u"",
mGeckoViewSessionContextId = <gNullChar> u"",
mInIsolatedMozBrowser = false,
mPartitionKey = <gNullChar> u"",
mPrivateBrowsingId = 0,
mUserContextId = 0
}, <No data fields>},
originNoSuffix_ = "https://www.marriott.com",
spec_ = "https://www.marriott.com/sign-in.mi",
domain_ = {
<mozilla::detail::MaybeStorage<nsTString<char>, false>> = {
<mozilla::detail::MaybeStorageBase<nsTString<char>, false>> = {
mStorage = {
val =
}
},
members of mozilla::detail::MaybeStorage<nsTString<char>, false>:
mIsSome = 0 '\000'
},
<mozilla::detail::Maybe_CopyMove_Enabler<nsTString<char>, false, true, true>> = {<No data fields>}, <No data fields>},
baseDomain_ = "marriott.com"
}
(pernosco) p *((ContentPrincipalInfo*)&aRight.mValue.VContentPrincipalInfo.u.mBytes)
$3 = {
attrs_ = {
<mozilla::dom::OriginAttributesDictionary> = {
<mozilla::dom::DictionaryBase> = {
mIsAnyMemberPresent = true
},
members of mozilla::dom::OriginAttributesDictionary:
mFirstPartyDomain = <gNullChar> u"",
mGeckoViewSessionContextId = <gNullChar> u"",
mInIsolatedMozBrowser = false,
mPartitionKey = u"(file,)",
mPrivateBrowsingId = 0,
mUserContextId = 0
}, <No data fields>},
originNoSuffix_ = "https://www.marriott.com",
spec_ = "https://www.marriott.com/sign-in.mi",
domain_ = {
<mozilla::detail::MaybeStorage<nsTString<char>, false>> = {
<mozilla::detail::MaybeStorageBase<nsTString<char>, false>> = {
mStorage = {
val =
}
},
members of mozilla::detail::MaybeStorage<nsTString<char>, false>:
mIsSome = 0 '\000'
},
<mozilla::detail::Maybe_CopyMove_Enabler<nsTString<char>, false, true, true>> = {<No data fields>}, <No data fields>},
baseDomain_ = "marriott.com"
}
1: The pretty printers in-tree could use a little more love to get rid of the verbosity on "domain_".
|
|
Reporter | |
Comment 12•8 months ago
|
||
Hello, I hope you are well. May I know when is the date of receiving the reward?
|
|
||
Comment 13•8 months ago
|
||
(In reply to ibrahim mohammed abdo mohammed ali from comment #12)
Hello, I hope you are well. May I know when is the date of receiving the reward?
Thanks for filing this! Please refer to the Client Bug Bounty Program to learn about eligible bugs. This bug has no security rating and thus most likely will not be eligible, as the tripped release assertion is already there to prevent users from bigger harm. That does not mean we should not take it serious (a crash is not a nice thing at all), and the reproduction case we have now will help us hopefully. Thanks for your support!
|
|
||
Updated•8 months ago
|
|
|
||
Comment 15•7 months ago
|
||
|
|
||
Comment 16•7 months ago
•
|
||
FWIW, I tried to comment the source code a bit, see WIP patch. It seems quite clear that the check from ServiceWorkerAllowedToControlWindow is not sufficient to test what SetController checks later? As there is a direct call path that leads us there I'd assume, the very same check should be just anticipated?
Copied from bug 1833789 comment 7:
From the crash reports, a number of crashes seem to be from game pages from https://gesoten.com/
I now see also quite a lot of outlook URLs, and the crash volume spiked up significantly since Jan 18. Interestingly the spike seems to have started with 121.0.1 which sounds unlikely looking at https://www.mozilla.org/en-US/firefox/121.0.1/releasenotes/ so maybe MS did some change to outlook that we are seeing in the data? Note also that the crashes seem to go significantly down on week-ends, which might point to office usage, too.
FWIW, 121 (bug 1864216) potentially changed the behavior for mailto handlers, I did not try to understand if that could lead to users coming to outlook.office.com more often in the browser.
|
|
||
Comment 17•6 months ago
|
||
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit BugBot documentation.
|
|
||
Comment 18•6 months ago
|
||
(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #17)
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit BugBot documentation.
I am not really seeing a strong downtrend in the graph, maybe we are just close to the border line.
|
||
Updated•5 months ago
|
Description
•