See bug #99769.
This is fixed in 3.4.2.
Created attachment 64438 [details, diff]
This one needs to be applied before the patch on the parent bug applies.
Created attachment 64439 [details, diff]
Official upstream patch for 3.3.1.
Created attachment 64440 [details, diff]
Official upstream patch for 3.4.1.
Created attachment 64960 [details]
Created attachment 64961 [details]
Created attachment 64962 [details]
KOffice is not affected this time. Any news about the common xpdf,gpdf,kde.org
Arches please test and mark stable/report back on this bug.
Carlo no news from upstream yet and you're free to commit, patches are already
public, though no advisories yet.
carlo: you can doublecheck the issue is fixed using a testcase PDF you will find
on toucan at ~koon/foo.pdf. This one should grow a file in /tmp until filesystem
is full. Kill your process in time :)
For gpdf they had to adapt the patch a little and when tested using the testcase
it revealed that the patched version wasn't working better :/ So better make
sure the patch indeed works.
NB: apparently when allanonJL tested the problem in gpdf, it was triggered by
going to the second page (just opening the first page didn't trigger the problem).
CCing weeve on this one - he's better suited for kde on sparc.
Add gmsoft for testing. He has already kde installed.
can carlo or other kde ppl do x86? I dont have kde.
(In reply to comment #10)
> carlo: you can doublecheck the issue is fixed using a testcase PDF you will find
Did it, all fine.
(In reply to comment #9)
> Carlo no news from upstream yet and you're free to commit, patches are already
> public, though no advisories yet.
You'll drive me crazy with this un-/disclosed vendor-sec sh.t. ;) On the kde
packager list Dirk Mueller used the word undisclosed for this issue at least.
(In reply to comment #13)
> can carlo or other kde ppl do x86? I dont have kde.
I'd have committed the ebuilds directly, if I had known that it is o.k. this time.
Here (~amd64) I'm both able to reproduce the bug with 3.4.1, and to fix it
with the given patch. It also works fine with 3.4.2.
This is how we handle this type of bug:
The third (and less secret) type of restricted bugs is the SEMI-PUBLIC bugs.
Semi-public bugs should be kept secret, but patches may be committed to
portage. This is generally when the vulnerability is not known to the general
public but could be accessed by anyone (patch in upstream CVS for example).
Can someone add me to bug #99769 so I can see what the problem is so I can test
to make sure the fix is working on SPARC?
Works fine on hppa. No more big file in /tmp and the second page is displayed
Looking good on SPARC, stablized kdegraphics.
This will be public on Tuesday. We still need the following keywords (unless
some arches are dropping support for 3.3.2):
kdegraphics-3.3.2-r3: alpha amd64 hppa ia64 mips ppc ppc64
kdegraphics-3.4.1-r1: amd64 ppc hppa
kpdf-3.4.1-r1: amd64 ppc ppc64 sparc
Alpha + ia64 stabilized.
marked kpdf-3.4.1-r1 and kdegraphics-3.3.2-r3 stable on ppc64.
Stable on amd64.
kpdf-3.4.1-r1 now stable on SPARC.
CC'ing ppc guys, please test and mark stable asap and sorry for the short
Stable on ppc.
Only needing hppa (and mips once this go public).
both version of kdegraphics stable on hppa. sorry for the delay
client-based DoS -> downgrading severity
mips please mark stable.
This is now public and ready for GLSA decision. I tend to vote NO.
I tend to vote NO too. DoS by social-engineer someone to open a file in KPDF ?
Or maybe we can make one once gpdf is also fixed ?
Waiting for common xpdf GLSA.
GLSA ID: 200508-08
kdegraphics-3.3.2-r3 stable on mips.