926074 - Firefox crashes when loading an mp4 as text/html.

Status: RESOLVED INCOMPLETE

(Core :: DOM: HTML Parser, defect)

Description

[Blake Winton (:bwinton) (:☕️)]

zedshaw twote "Well, looks like I can consistently crash Chrome and Firefox by giving it a .mp4 file but saying it's text/html on accident. Lovely."
When asked for a test url, he replied: "Make a 20MB .html file full of /dev/urandom and load it a few times."

Seems like something our fuzzers would have caught, but perhaps we aren't checking this case…

Comment 1

[Wayne Mery (:wsmwk)]

(In reply to Blake Winton (:bwinton) from comment #0)
> Seems like something our fuzzers would have caught, but perhaps we aren't
> checking this case…

Perhaps Gary will know.

We have other reported examples, like rename an ISO to html or txt.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Adding other fuzzing people who might also know how to move this forward.

Comment 3

[Jesse Ruderman]

I couldn't get it to crash (Firefox Nightly on Mac). I tried a few MP4 files (~30MB and ~60MB) and a few iterations of "head -c 20000000 /dev/urandom > ~/20MB.html".

Memory usage was high, though. According to about:memory, 20MB of garbage caused Firefox to allocate 2GB, almost all as nsInlineFrame. On Win32 that would be about enough to OOM.

Blake, can you ask zedshaw to respond here, since his Twitter account is private? I'd like to know what OS he uses. Specific files that crash, or crash reports from about:crashes, would be great.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

Asked!  https://twitter.com/bwinton/status/544199837567451136

Comment 5

[Henri Sivonen (:hsivonen)]

My bet is that this is OOM on 32-bit Windows with some byte pattern that causes a lot of data to end up as a tag name, attribute name or attribute value.

Comment 6

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Attachment: mem_usage.png

Hi,

I've only managed to reproduce a crash when trying to open 2 files(a 70mb .mp4 and a 120mb .html). I have loaded the files in two separate tabs and after a few minutes, one of the tabs crashed with the following signature [@ OOM | unknown | NS_ABORT_OOM | nsIPresShell::AllocateFrame ] on Windows 7 and 8.1 x86 on the latest Nightly (47.0a1). On Windows 10 however I haven't managed to reproduce a crash. I even tried to load 3 such files in different tabs, but that only ate up all my RAM as seen in mem_usage.png.

Here are the testcase files that I have used to test this issue.
https://drive.google.com/file/d/0B8ICzPJynbchUjBxdFJKY0g2dzQ/view?usp=sharing
https://drive.google.com/file/d/0B8ICzPJynbchOFNGTXl0Q09ScjA/view?usp=sharing
https://drive.google.com/file/d/0B8ICzPJynbchMWc2aE9rT193bWs/view?usp=sharing

The testcases I have used seem to work consistently. 

Thanks,
Cipri

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Should this issue still occur, feel free to reopen this. A crash report is appreciated and helpful.