Bug 19315 - Large Images Freeze The Whole Computer
Summary: Large Images Freeze The Whole Computer
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium critical
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Keywords: x12
Depends on:
Reported: 2008-12-28 19:36 UTC by Synx
Modified: 2011-10-15 14:04 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

A 24000x24000 red square, may lock up your system! (57.67 KB, image/png)
2008-12-28 19:36 UTC, Synx
no flags Details

Description Synx 2008-12-28 19:36:01 UTC
Created attachment 21533 [details]
A 24000x24000 red square, may lock up your system!

There's a limit to how big an image can load in Firefox. Not nearly low enough though. So I managed to craft an image that will grind just about any system to a halt that's running X. It's simply a 24000x24000 red square, not any image anyone would practically use, but one a malicious user might make use of. I can see how it might lead to politics and FUD to have a simple 60K image that just about destroys any machine using X.

What happens, I think, is that Firefox or any other image client will decompress the image and send it to an X server. The server will attempt to allocate enough memory for the entire image, ignoring if that image is too big for available memory or for the screen, or for basic sanity. So a 24000x24000 image decompressed and mapped onto a 32 bit colorspace would be around 2.3 gigabytes of RAM. Not good if you have 2 gigabytes like me, or 512MB many people have.

I think the uncompressed image data gets replicated more than once too, but I can't confirm that because my system freezes when that much memory gets allocated. It can't page out to disk fast enough, and it takes me about 5 minutes to kill Firefox so that the X server can stop allocating all that memory.

I don't know the solution really. Ideally you'd want to clip the image and only allocate as much memory as the part of it showing on the screen, but I can see how that might get expensive or convoluted. Not displaying the image at all might work, but maybe the burden of blocking it should be on the image clients, not on X? Maybe all involved in the process should check for extra large images? Maybe I just don't understand the situation and this is an old problem people solved a long time ago?

At any rate, view this image at your own risk. Be ready to kill the window fast if it starts filling up memory, because the mouse and keyboard almost totally stop responding, at least it has for me and my other friends running X.

Don't spread this around, but my friends running the Microsoft GUI had no problems, saw a giant red square with no slowdown. I haven't had a chance to try it on an Apple yet.

Also I tried X -version but it said 1.4.2-9. I don't know what the above versions in this bug database are for ._.
Comment 1 Jeremy Huddleston Sequoia 2011-10-15 14:04:43 UTC
I'm not really sure what we can do here.  The problem here seems to be a 
protocol one.  The caller is likely calling XCreatePixmapFromBitmapData(...) 
(or XCreatePixmap followed by XPutImage) which sends data from the client to 
the server and provides the client with an XID for the Pixmap.  The server 
needs to store this data since it can't go and ask the client for it later.

Firefox can handle this better by being sensitive to this issue.  If the image 
being loaded is larger than the screen dimensions by a certain degree, they 
should only create a pixmap for a subset of the pixmap.

Closing as NOTOURBUG and tagging for x12 consideration if that ever happens.

Please report this in the mozilla bugzilla and report the bug URL here for 
cross reference.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.