1687269 - Crash in [@ nsReadFromRawBuffer]

Status: RESOLVED DUPLICATE of bug 1740797

(Core :: DOM: File, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/5bff272f-84df-4640-84ee-0f3410210118

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0 libsystem_platform.dylib _platform_memmove$VARIANT$Haswell 
1 XUL nsReadFromRawBuffer xpcom/io/nsPipe3.cpp:1715
2 XUL nsPipeOutputStream::WriteSegments xpcom/io/nsPipe3.cpp:1684
3 XUL nsStreamCopierIB::ConsumeInputBuffer xpcom/io/nsStreamUtils.cpp:501
4 XUL nsStringInputStream::ReadSegments xpcom/io/nsStringStream.cpp:316
5 XUL nsStreamCopierIB::DoCopy xpcom/io/nsStreamUtils.cpp:519
6 XUL nsAStreamCopier::Process xpcom/io/nsStreamUtils.cpp:302
7 XUL {virtual override thunk} 
8 XUL nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:301
9 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200

Not a new crash, this appears to be like we're reading past (or before?) a buffer. The comments in the crash reports mention this is happening at the end of a large transfer while saving a file. There's both mentions of trying to download stuff from https://mega.nz and people saving recorded videos.

This only seem to affect Linux and macOS but there might be a different signature for Windows.

Comment 1

[Gabriele Svelto [:gsvelto]]

Interestingly there's almost no volume before September 14 2020, this looks like some kind of regression around that time.

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Over to XPCOM to be retriaged.
This looks like a UAF to me.

Comment 3

[Andrew McCreight [:mccr8]]

Why does this look like a UAF to you? Are there some reports with a poison value that you saw?

Comment 4

[Valentin Gosu [:valentin] (he/him)]

(In reply to Andrew McCreight [:mccr8] from comment #3)

Why does this look like a UAF to you? Are there some reports with a poison value that you saw?

No, sorry about that. I'm not sure what made me think UAF while looking at the stack trace.

Comment 5

[Andrew McCreight [:mccr8]]

I suppose it does look rather like a buffer overflow of some sort.

Comment 6

[Gabriele Svelto [:gsvelto]]

This appears not to be macOS-specific. I found Windows signatures with significant volume and the same stack trace.

Comment 7

[Gabriele Svelto [:gsvelto]]

I've scoured the comments of the Windows crashes and this seems really related to large file downloads: there are several crashes happening on mega.nz while downloading files that appear to be between 1.5 and 4GB in size. Other reporters mention trying to download large files (3, 4 and 5GB) appear in the comments. I suppose we could try reproducing the bug that way?

FYI if you read the comments be aware that there's a pretty large amount of profanity in there. These are frustrated users who waited for hours for a download and then Firefox crashed on them.

Comment 8

[:Gijs (he/him)]

In case it helps, mega.nz does... strange... stuff where they put data into blobs to "encrypt" them or something, see e.g. bug 1584898, bug 1700187.

Comment 10

[Andrew McCreight [:mccr8]]

Bug 1740797 has a test case with a similar looking stack.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

Moving this to the same component as bug 1740797 where the investigation is being done.