1416227 - Firefox 58.0a1 Crash Report [@ mozilla::net::nsHttpChannel::ProcessId ]

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, defect, P2)

Description

[kernp25]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171110100139

Steps to reproduce:

This code crashes firefox after some time (e.g. if you reload all tabs, load some sites...)

function listener(details) {
  let filter = browser.webRequest.filterResponseData(details.requestId);
  filter.ondata = event => {
    filter.write(event.data);
    filter.disconnect();
  }
}

browser.webRequest.onBeforeRequest.addListener(
  listener,
  {urls: ["<all_urls>"]},
  ["blocking"]
);


Actual results:

Here are the crash reports:
https://crash-stats.mozilla.com/report/index/bp-4908d9ee-4279-48a9-9d17-0dbe60171110
https://crash-stats.mozilla.com/report/index/bp-35ee4760-2fb8-44ff-b96d-bb0970171110
https://crash-stats.mozilla.com/report/index/bp-cf7ffdd0-f0f1-4fc1-bb74-1d1780171110
https://crash-stats.mozilla.com/report/index/bp-6c4b127e-c43f-4526-afd7-98c360171110

Comment 1

[kernp25]

My Firefox version:
58.0a1 (2017-11-10) (32-Bit)

Comment 2

[kernp25]

I think this is the crash report for the problem:
https://crash-stats.mozilla.com/report/index/bp-6c4b127e-c43f-4526-afd7-98c360171110

Comment 3

[Kris Maglione [:kmag]]

Hm. Looks like a UAF on the HttpChannelParent. Not entirely sure how that's possible, though. The vtable lookup for the QueryInterface should have failed, in that case...

Comment 4

[Julien Cristau [:jcristau] (back April 22)]

hiding as UAF.

Comment 6

[[:philipp]]

the signature started getting more common starting on 2018-01-10. also copying over some info from the dupe:

this crash signature is regressing in firefox 57 with bug 1255894. on release it's 100% correlated to the presence of the "NoScript Security Suite" addon and many user comments link the crash to interacting with the XSS popup, a couple of times in relation to tumblr as well:
https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Anet%3A%3AnsHttpChannel%3A%3AProcessId&date=%3E%3D2017-12-24#comments

Comment 7

[kernp25]

Maybe this has been fixed now?
https://bugzilla.mozilla.org/show_bug.cgi?id=1430508

Comment 8

[Giorgio Maone [:ma1]]

(In reply to [:philipp] from comment #6)

> this crash signature is regressing in firefox 57 with bug 1255894. on
> release it's 100% correlated to the presence of the "NoScript Security
> Suite" addon and many user comments link the crash to interacting with the
> XSS popup, a couple of times in relation to tumblr as well:

Indeed, on some Tumblr pages a XSS false positive is triggered causing NoScript to attempt a window.name sanitization involving filterResponseData().
Not sure if this is relevant, but when this happens after a "XSS popup" as the reporters call it, the channel has been suspended for a certain time (until the popup is dismissed) and then resumed before the stream filter being used, which might be the actual trigger of bug 1430508.
Both things (the false positive and using stream filters to sanitize) are going away from NoScript in Firefox 58 (thanks to contentScripts.register()), but I do hope the stream filter is fixed because there are other useful usages for that.

Comment 9

[Kris Maglione [:kmag]]

Yes, bug 1430508 should have fixed this.

(In reply to Giorgio Maone [:mao] from comment #8)
> Not sure if this is relevant, but when this happens after a "XSS popup" as
> the reporters call it, the channel has been suspended for a certain time
> (until the popup is dismissed) and then resumed before the stream filter
> being used, which might be the actual trigger of bug 1430508.

Yes, it's probably relevant. This mostly seems to happen when the content process that initiated a request shuts down before we try to attach a stream filter. Suspending the request for an extended period of time before attaching the stream filter would tend to make that more likely.