Investigate bug 1732249
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
People
(Reporter: dragana, Unassigned)
References
Details
(Keywords: crash, csectype-wildptr, sec-moderate, Whiteboard: [maybe fixed by 1797370][necko-triaged])
Crash Data
Attachments
(1 obsolete file)
We will add some diagnostic asserts to figure out why certificates are not already set when response is received.
Reporter | ||
Comment 1•3 years ago
|
||
Pushed by ddamjanovic@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5bb05a86bd2e Add assertions to make sure certificates are set if a handshake succeeds. r=necko-reviewers,valentin
Comment 3•3 years ago
|
||
bugherder |
Comment 4•3 years ago
•
|
||
Backed out changeset 5bb05a86bd2e (Bug 1732885) for causing networking crashes. a=backout
Backout link: https://hg.mozilla.org/mozilla-central/rev/75ff6f392acad0ccffff8a6484dfcb0bfd1bc408
Autoland backout link: https://hg.mozilla.org/mozilla-central/rev/75ff6f392acad0ccffff8a6484dfcb0bfd1bc408
Updated•3 years ago
|
Updated•3 years ago
|
Comment 6•3 years ago
|
||
I hit this yesterday on my Android nightly, too and thus took a look. At SetServerCert (which seems to be the only place we set mServerCert
) there is a possible and probably expected code path that leaves us with a nullptr
inside mServerCert
if we have an mListener
set. That means probably that we cannot expect an existing mSecurityInfo
to always carry an initialized certificate?
Reporter | ||
Comment 7•3 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #6)
I hit this yesterday on my Android nightly, too and thus took a look. At SetServerCert (which seems to be the only place we set
mServerCert
) there is a possible and probably expected code path that leaves us with anullptr
insidemServerCert
if we have anmListener
set. That means probably that we cannot expect an existingmSecurityInfo
to always carry an initialized certificate?
This is a server side socket, httpTransactions never hit that code.
Comment 8•3 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:dragana, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Reporter | ||
Comment 9•2 years ago
|
||
The patch was made to investigate an issue, it will not land permanently.
Updated•2 years ago
|
Reporter | ||
Comment 10•2 years ago
|
||
I will not have time to work on this.
Comment 11•1 year ago
|
||
often-wildptr crashes; ~3-4 per week.
No CheckCert() failures in the last 6 months, so the diagnostic appears to be showing us nothing.
A fair number of the wildptr crashes seem to be at the call to HandleContent()
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
The severity field for this bug is set to S3. However, the bug is flagged with the sec-high
keyword.
:valentin, could you consider increasing the severity of this security bug?
For more information, please visit auto_nag documentation.
It's stalled.
Comment 14•1 year ago
|
||
I don't see any crashes in recent builds. a bunch of 102.5 which was the current ESR until last week, but nothing on main newer that 105
Maybe this is WFM now?
Comment 15•1 year ago
|
||
If I were to guess I think it was bug 1797370 that fixed this. Thank you for the regression range Ryan!
Still no more crashes. Closing as WFM.
Updated•1 year ago
|
Comment 18•1 year ago
|
||
Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.
Updated•10 months ago
|
Updated•9 months ago
|
Description
•