From #theora: 15:48 < kinetik> 1.1 will be in 3.6 15:48 < derf> kinetik: I highly recommend you apply the patch in r16702, then. 15:50 < derf> I didn't actually do the analysis to see if that bug lead to an exploitable vulnerability. 15:50 < derf> But I figure better safe than sorry. 15:53 < kinetik> does a similar problem exist on the 1.0 code? 15:53 < derf> kinetik: No. That code was all-new in 1.1. 15:54 < derf> It was part of the changes needed to actually check malloc() returns.
This should probably block 1.9.2. 1.9.1 is not affected as we've still got Theora 1.0 there. I'll get a patch up ASAP.
Assignee: nobody → kinetik
Flags: blocking1.9.2? → blocking1.9.2+
Comment on attachment 412758 [details] [diff] [review] patch v0 Does README_MOZILLA need to be updated to state the svn revision?
Attachment #412758 - Flags: review?(chris.double) → review+
Doh, so it was!
I've done the analysis now, and I don't believe the bug is exploitable with the code as shipped (i.e., with OC_HUFF_SLUSH #define'd to 1). But again, better safe than sorry.
(In reply to comment #6) > I've done the analysis now, and I don't believe the bug is exploitable with the > code as shipped (i.e., with OC_HUFF_SLUSH #define'd to 1). But again, better > safe than sorry. Do you know of anybody or any distro that has changes that would make this exploitable (I assume OC_HUFF_SLUSH == 0 would be bad)? I can bring this up on vendor-sec if you think it's possible that some distro would actually be vulnerable to this.
Setting OC_HUFF_SLUSH to 0 should have caused a segfault on almost every Theora file in existence. I'm pretty sure if a distro had done that, they would have noticed.
Whiteboard: [needs landing]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 192 landing]
You need to log in before you can comment on or make changes to this bug.