1825645 - Use-after-free crash in [@ mozilla::net::nsStandardURL::nsStandardURL] mostly from a single machine

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect, P2)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/0abfe9e9-1fd1-41c9-9916-28ffe0230328

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  nsCOMPtr_base::assign_assuming_AddRef  xpcom/base/nsCOMPtr.h:377
0  xul.dll  nsCOMPtr_base::assign_with_AddRef  xpcom/base/nsCOMPtr.cpp:41
1  xul.dll  nsCOMPtr<nsIURLParser>::operator=  xpcom/base/nsCOMPtr.h:706
1  xul.dll  mozilla::net::nsStandardURL::nsStandardURL  netwerk/base/nsStandardURL.cpp:218
1  xul.dll  mozilla::net::nsStandardURL::TemplatedMutator<mozilla::net::nsStandardURL>::Create  netwerk/base/nsStandardURL.h:500
1  xul.dll  mozilla::net::nsStandardURL::TemplatedMutator<mozilla::net::nsStandardURL>::Init  netwerk/base/nsStandardURL.h:441
2  xul.dll  NS_MutateURI::Apply  dist/include/nsIURIMutator.h:592
2  xul.dll  NewStandardURI  netwerk/base/nsNetUtil.cpp:1755
3  xul.dll  NS_NewURI  netwerk/base/nsNetUtil.cpp:1854
4  xul.dll  mozilla::dom::URL::Constructor  dom/url/URL.cpp:82

There aren't a lot of these crashes, 8 in the last month, but 7 of those are on the jemalloc poison value, and only on 112 and 113, so maybe there's something we can do here.

Bug 1715960 is also on file for use-after-free crashes related to nsStandardURL, but I don't know if it is related or not.

Comment 1

[Andrew McCreight [:mccr8]]

These crashes are from a variety of install times, but a number of them have URLs from a couple of universities in China, and the UAF crashes all are on the same graphics hardware, so it could be a single person with buggy hardware.

Comment 2

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

The bad hardware theory seems to make the most sense.
Looking at the code, it seems like the only way net_GetStdURLParser could return a pointer to a freed object would be if net_ShutdownURLHelper gets called between the call to net_GetStdURLParser and the assigning of the pointer.
Considering these crashes are on the main thread, that doesn't seem possible.

Comment 3

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

We'll take another look in two weeks - maybe we'll have more crash stacks that can lead to other insights.

Comment 4

[Andrew McCreight [:mccr8]]

There are still a steady trickle of these, but the last 4 all have the exact same Adapter Device ID.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

90% of the crashes, and 100% of the e5e5 crashes are from zh-CN with cpu "family 6 model 151 stepping 5 " -> a single machine. Doesn't mean there isn't an issue, but very likely it's something specific to this user or his machine. Most of the e5e5 URLs are from https://moa.xmu.edu.cn/... others are scattered but consistent with one user.