[1.8 branch] XBM appears to draw uninitialized memory

VERIFIED FIXED

Status

()

Core
ImageLib
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: Jesse Ruderman, Assigned: vlad)

Tracking

({privacy, testcase, verified1.8.1.17})

1.8 Branch
x86
Mac OS X
privacy, testcase, verified1.8.1.17
Points:
---
Bug Flags:
blocking1.8.1.17 +
blocking1.8.0.next +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
Created attachment 332877 [details]
testcase (XBM)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

Loading this XBM file makes Firefox 2 draw some random pixels.  They're different each time the image is reloaded, so it seems like Firefox might be displaying contents of uninitialized memory.

In Firefox 3 and trunk, I just see white, but I don't know whether the bug was really fixed (or whether it was fixed intentionally).

Billy Hoffman pointed this bug out during his talk at Black Hat today.
(Reporter)

Updated

9 years ago
Flags: blocking1.8.1.17?
Vlad, can you find an owner for this?
Assignee: nobody → vladimir
It would be nice to plug this in the next FF2 update since it's public. probably a memset() is all it needs.
Keywords: privacy
Whiteboard: [sg:low]
(Reporter)

Updated

9 years ago
Keywords: testcase
Flags: blocking1.8.1.17? → blocking1.8.1.17+
Presumably this was fixed on trunk by bug 376471?
(Assignee)

Comment 4

9 years ago
Created attachment 334923 [details] [diff] [review]
potential fix?

I can't actually get 1.8.1 to build on my mac any more; this bug is OSX-only, right?  This is likely to fix it if so; if someone has a 1.8.1 build they could try this out on, that'd be helpful.
Comment on attachment 334923 [details] [diff] [review]
potential fix?

Dan, can you test this patch?
Attachment #334923 - Flags: review?(dveditz)
Well, yes, I can test the mac-only patch, but this is not a mac-only bug.
OS: Mac OS X → All
Hardware: PC → All
(Assignee)

Comment 7

9 years ago
Ah, I didn't realize it wasn't Mac-only -- I can test 1.8.1 on linux.
The patch didn't seem to work on the Mac. Did I not clobber enough?
OS: All → Mac OS X
Hardware: All → PC
(Assignee)

Comment 9

9 years ago
Created attachment 335439 [details] [diff] [review]
fix

Looks like this buffer isn't being zero'd out if we happen to bail early.  Do so.
Attachment #334923 - Attachment is obsolete: true
Attachment #335439 - Flags: review?(dveditz)
Attachment #334923 - Flags: review?(dveditz)
Comment on attachment 335439 [details] [diff] [review]
fix

Tested on Mac and Windows, r=dveditz

Approved for 1.8.1.17, a=dveditz for release-drivers.
Attachment #335439 - Flags: review?(dveditz)
Attachment #335439 - Flags: review+
Attachment #335439 - Flags: approval1.8.1.17+
(Assignee)

Comment 11

9 years ago
Checking in nsXBMDecoder.cpp;
/cvsroot/mozilla/modules/libpr0n/decoders/xbm/nsXBMDecoder.cpp,v  <--  nsXBMDecoder.cpp
new revision: 1.17.2.2; previous revision: 1.17.2.1
done

This doesn't seem to be present on trunk (and indeed, the offending code is gone from trunk -- memory allocation happens in a different spot).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.8.1.17
Resolution: --- → FIXED
Version: Trunk → 1.8 Branch
Verified for 1.8.1.17 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.17) Gecko/2008082910 Firefox/2.0.0.17.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.17 → verified1.8.1.17

Updated

9 years ago
Flags: blocking1.8.0.15+

Comment 13

9 years ago
Comment on attachment 335439 [details] [diff] [review]
fix

a=asac for 1.8.0.15
Attachment #335439 - Flags: approval1.8.0.15+
You need to log in before you can comment on or make changes to this bug.