Open Bug 926074 Opened 7 years ago Updated 5 years ago

Firefox crashes when loading an mp4 as text/html.

Categories

(Core :: DOM: HTML Parser, defect)

x86
macOS
defect
Not set
critical

Tracking

()

People

(Reporter: bwinton, Unassigned)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

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…
(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.
Flags: needinfo?(gary)
Adding other fuzzing people who might also know how to move this forward.
Flags: needinfo?(gary)
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.
Flags: needinfo?(bwinton)
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.
Severity: normal → critical
Keywords: crash
Attached image 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
You need to log in before you can comment on or make changes to this bug.