Bug 135126 - gpdf crashes system opening specific file (DoS)
Summary: gpdf crashes system opening specific file (DoS)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gpdf
Version: 2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
URL: http://sco.tuxrocks.com/Docs/Novell/N...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-08 20:49 UTC by Robert Clark
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-06 13:42:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Robert Clark 2004-10-08 20:49:25 UTC
Opening the pdf file at the URL with gpdf causes gpdf to consume more
and more virtual memory eventually crashing the system and requiring a
hard reset.

This is reproducable as follows:

1) Download the file.
2) Open a terminal and run top.
3) Open a terminal and run gpdf Novell-52.pdf.

I see gnome-pdf-viewer immediately allocating ~ 600MB and continuing
to allocate memory until the system starts thrashing. Eventually, X
abruptly hangs and all disk activity ceases. I suspect that the kernel
has crashed at this point.

I've tried killing -9 gpdf & gnome-pdf-viewer during the thrashing
phase but the system still goes on to lock up.

This is with gdpf-0.131-2 & kernel-2.6.8-1.521smp. My system has 768MB
real memory & ~ 488MB of swap.

Comment 1 Marco Pesenti Gritti 2004-10-13 14:44:16 UTC
It works fine here with gpdf-2.8.0-2.

Comment 2 Robert Clark 2004-11-03 20:45:41 UTC
The recent update to gpdf-2.8.0-4.1.fc2 fixes this for FC2.

Does this still need to be addressed in FC1?


Comment 3 Marco Pesenti Gritti 2004-11-06 13:42:23 UTC
Oh apparently someone pushed it in updates already. No I dont think we
can backport this to FC1.


Note You need to log in before you can comment on or make changes to this bug.