Tracking Bug for crashers found in Ogg by taviso-fuzz

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: johnath, Unassigned)

Tracking

(Blocks: 1 bug, {meta})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:nse meta])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
More details incoming - Lucas has a taviso-fuzz instance running, generating files, and producing an awful lot of crashers.
Flags: blocking1.9.1?
Keywords: meta
(Reporter)

Comment 1

9 years ago
Slightly more detail - running this fuzzer overnight, Lucas found a couple thousand crashers.  It's not clear if this is all resulting from one or two problems, or if there are literally thousands of problems.  Lucas is going to get everything online - the fuzzer and the known-crashing files, asap. Individual crashers should be filed as blocking this bug.
Flags: blocking1.9.1? → blocking1.9.1+

Comment 3

9 years ago
first couple of crashes we have seen look related to bug 487519
(Reporter)

Comment 4

9 years ago
So far every file I've tried has crashed in the same place as this one, vorbis_synthesis:49, which is bug 487519, as chofmann says.

http://crash-stats.mozilla.com/report/index/d5d89420-bcbc-4f54-976c-d91772090527?p=1

    
d5d89420-bcbc-4f54-976c-d91772090527	27/05/09	6:15 PM
05034a87-2952-4abe-829d-4d2742090527	27/05/09	6:14 PM
96550895-b628-432c-9825-a56a42090527	27/05/09	6:11 PM
e0199752-d2a6-46e4-b01d-9cf6b2090527	27/05/09	6:11 PM
aa297233-01d5-454e-a8fa-7e3a22090527	27/05/09	6:10 PM
457a71de-217b-406e-8915-e068f2090527	27/05/09	6:07 PM
843dd6fd-af05-4a0d-8af6-812ac2090527	27/05/09	5:57 PM
9c98e250-6cf8-4117-849b-17ac42090527	27/05/09	5:56 PM
00ee669a-4166-4a98-9770-6782b2090527	27/05/09	5:56 PM
Created attachment 379983 [details]
taviso-fuzz hacked for ogg test file

In about:config, set
browser.link.open_newwindow=1
browser.link.open_newwindow.restriction=0

In application.ini, set
[Crash Reporter]
Enabled=0

then, from within the fuzz-0.4 directory, run: 
./fuzz -T 3 "../firefox-trunk-5-29-09/run-mozilla.sh ../firefox-trunk-5-29-09/firefox-bin __FILE__" video-1.ogg

... replacing the Firefox path with your correct location, and video-1.ogg with whatever test file you intend to use.
(Reporter)

Comment 6

9 years ago
And while those were all from the initial batch, testing number 2500 from batch 2 results in the same stack.

http://crash-stats.mozilla.com/report/index/e2d17fc7-3866-4e0e-8627-d63b72090527?p=1
I confirmed that all 35 oggs in batch1 crash at the same place (trunk debug build on mac). Here's the script I used to obtain the call stacks from each crash.  It just runs gdb with a list of instructions to run firefox on each ogg and log the back trace to a file corresponding to the ogg file's name. I used grep to look for the same pattern in each log file, and found each back trace referenced vorbis_synthesis.c:49.

---
#!/bin/bash
FIREFOX=/Users/sstamm/Documents/src/firefox/dbg-ff/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin
OGGS=/Users/sstamm/Desktop/ogg.batch1

for x in $OGGS/*.ogg; do
  echo "set logging file $x.log" > script.gdb
  echo "set logging on"         >> script.gdb
  echo "run -p dev $OGGS/$x "   >> script.gdb
  echo "bt"                     >> script.gdb
  echo "set logging off"        >> script.gdb
  echo "kill"                   >> script.gdb
  echo "quit"                   >> script.gdb
  gdb $FIREFOX -x script.gdb 
done

Comment 8

9 years ago
I've tried to reproduce the crash(es) with the latest trunk version of FF, but none of the Ogg files I found in the attached zip archive caused any crash for me.

maybe it was some other Ogg file(s) that caused the crash(es)?
I crash with the ogg file in bug 495129, when it is loaded from local disk. Do not crash when loaded from the bugzilla page.

I've crashed with today's Shiretoko nightly and an older one, as well as a debug Shiretoko from about a week ago. I did not crash with a debug Minefield from 20090517, but I crash with a nightly Minefield from that date as well as today.
FWIW, we usually don't block on meta bugs - do we actually want to block on bug 487519 instead?
We want to block on knowing the scale of the issue here, and then we'll want to pick which sub-bugs on which to block instead, IMO?

Comment 12

9 years ago
Crash in URL seems to be fixed by patches in bug 495129.
Per comment 11, scope is understood to be mostly bug 495129 which is already blocking, so removing blocking from this one.
Flags: blocking1.9.1+ → blocking1.9.1-
Whiteboard: [sg:nse meta]
Bug 495129 was fixed a while ago.  No other bugs are tracked by this one, closing.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.