I see a fair number of crashes like this on Nightly: https://crash-stats.mozilla.com/report/index/e13e8124-1e55-4560-b40c-e13e92150317#allthreads I'm not sure how bad of a security problem this is given that we're always crashing but maybe the code is otherwise trying to use these objects.

FileSizeAndDateRunnable (and anything that jumps around several threads) should be holding FileImpl, not nsIDOMFile.

I guess that's because FileImpl has threadsafe AddRef and Release?

This looks like a regression from bug 910384. How bad is this security-wise?

Comment on attachment 8579618 [details] [diff] [review] patch Review of attachment 8579618 [details] [diff] [review]: ----------------------------------------------------------------- Yeah, FileImpl is the threadsafe (and potentially shared) piece for blobs. Blob/File are the DOM parts, and they're CC'd, etc.

This is e10s-only, so it only affects Nightly.

Ah, great.

Comment on attachment 8579618 [details] [diff] [review] patch Review of attachment 8579618 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/ipc/FilePickerParent.h @@ +7,4 @@ > #ifndef mozilla_dom_FilePickerParent_h > #define mozilla_dom_FilePickerParent_h > > #include "nsIDOMFile.h" Oh, you might be able to lose this now.

I'm going to mark this as moderate, because it seems like it would be pretty hard to exploit. Note that we're hitting a release-mode assert here, so somehow you'd have to get this runnable to run some code before any CC-ed object is addrefed or released, plus whatever trickiness there is to exploit any race condition. It would still be nice to get this fixed so we can find other threading issued without digging through all of the crashes for this signature.

Does this affect B2G at all?

No, I believe they have their own separate file picker.