User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11 Build Identifier: mozilla-central revision e1ae3719e72a Segmentation fault when playing corrupted ogg theora file (attached). Reproducible: Always Steps to Reproduce: 1. Load attached file. Actual Results: firefox crashes Expected Results: some sort of "this file is corrupted" message
This appears to be the kind of "small enough to pass malloc, big enough to fail when the kernel actually goes to map pages" test case I warned about in https://bugzilla.mozilla.org/show_bug.cgi?id=504843, or at least fairly close. It decodes fine for me on x86-64 (producing 3.1 GB of output, or 7 frames).
Those show up as signal 11 (segfault)? :( How can we distinguish them from actual segfaults?
The solution proposed in that bug, adding a "reasonable resolution" check to liboggplay or restructuring the API so that Firefox can add such a check before a decoder is actually created, should still apply here. With this file, libtheora succeeds at allocating a decoder, and fails while trying to fill in the decoded token buffer, which is not touched during initialization. A slightly larger resolution might have even failed trying to write to pages during initialization.
(In reply to comment #3) > It decodes fine for me on x86-64 (producing 3.1 GB of output, or 7 frames). Any idea where it's getting the data to decode 3.1 GB of output?
The number of blocks in a frame is defined in the file header. The decoder will always generate data for that many blocks, regardless of the size of an input packet. Even a zero-byte packet is legal (it indicates a dropped frame, e.g., all the contents are the same as the previous frame).
If this is a DoS can we unhide the bug?
Actually, I probably mislabeled this. Going from https://bugzilla.mozilla.org/show_bug.cgi?id=504843#c11, this might be exploitable if the file is modified slightly and is opened under low memory situations. Marking as sg:low and keeping closed, unless someone thinks I'm being too paranoid or unreasonable.
Whiteboard: [sg:DoS] null deref → [sg:low] null deref (malloc failure)
I don't understand that concern. When the OS says "that page I gave you is not actually available", it's still a safe segfault.
Ah - I see. tterribe was saying that it would still crash even if malloc's return value was checked, not that it wasn't safe. Back to sg:DoS.
Whiteboard: [sg:low] null deref (malloc failure) → [sg:DoS] null deref
Opening this, seems like people are in agreement that this is a safe crash.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 504843
You need to log in before you can comment on or make changes to this bug.