Bugzilla Bug 202351

Meder Kydyraliev (Google Security) reported an integer overflow in exiv2.

Attaching upstream committed patch, one line change was necessary to get it to
apply to 0.13.

Stefan, please advise.

Created an attachment (id=138527) [details]
exiv2-CVE-2007-6353.patch

That patch won't compile due to wrong usage of static_cast, I will upload the
fixed patch.

Created an attachment (id=138536) [details]
Fix static_cast usage

ok, I have a look at it and try to commit that fix asap. Thanks for reporting.

one question: is this bug already fixed in exiv2-0.15?

if so, then I would suggest to get 0.15 stable and remove 0.13. IMHO that would
be the best solution.

(In reply to comment #5)
> one question: is this bug already fixed in exiv2-0.15?
> 
> if so, then I would suggest to get 0.15 stable and remove 0.13. IMHO that would
> be the best solution.

No, it is not. The patch should apply to 0.15 though. If you are more
comfortable with bumping to an actual release than patching, you could ask
upstream for a security release.

Oh, and Ismail - thanks for the corrected patch!

(In reply to comment #7)
> Oh, and Ismail - thanks for the corrected patch!

Thats my pleasure. 

ok, currently we have 3 versions in portage. 0.13 which is stable and 0.14/0.15
which are testing. So I will remove 0.14 and patch 0.13.

But what to do with 0.15? Is there a patch already or can I use the 0.13 patch
also?

(In reply to comment #9)
> ok, currently we have 3 versions in portage. 0.13 which is stable and 0.14/0.15
> which are testing. So I will remove 0.14 and patch 0.13.
> 
> But what to do with 0.15? Is there a patch already or can I use the 0.13 patch
> also?

Since src/exif.cpp did not change at all between 0.13 and 0.15, whichever you
patch is fine. There are several options, it's your choice as maintainer:

1) Patch 0.13, remove 0.14 and 0.15.
2) Patch 0.13, patch 0.15 with 0.13 staying stable. (remove 0.14 after that)
3) Patch 0.15 with 0.15 going stable. (remove 0.13 and 0.14 after that)

I'd go with (3) if you would stable 0.15 anyway soon, otherwise (2). (1) if you
are lazy, but it will mean ~arch user's are going to downgrade their copies.

ok, what I did:

1. removed 0.14 completely
2. revbumped 0.15 to 0.15-1 and removed 0.15
3. revbumped 0.13 to 0.13-1 and switched to testing

since the patch looks sane, it should be easy to stablize 0.13-r1 after a few
tests. Furthermore, we should stabalize 0.15-r1 afterwards.

(In reply to comment #8)
> (In reply to comment #7)
> > Oh, and Ismail - thanks for the corrected patch!
> 
> Thats my pleasure. 

Did you contact upstream about the issue in the patch or does this only affect
the releases?

(In reply to comment #12)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Oh, and Ismail - thanks for the corrected patch!
> > 
> > Thats my pleasure. 
> 
> Did you contact upstream about the issue in the patch or does this only affect
> the releases?

I didn't contact upstream as I guessed they would fix it once it fails to
compile as the error is obvious.

(In reply to comment #13)
> I didn't contact upstream as I guessed they would fix it once it fails to
> compile as the error is obvious.

Hm, the trunk compiles fine for me. However, you are right, on the releases,
the patch won't work.

Arches, please test and mark stable media-gfx/exiv2-0.13-r1.
Target keywords : "alpha amd64 ia64 ppc sparc x86"

x86 stable

Stable for sparc.  Everything as expected.

alpha/ia64 stable

ppc stable

amd64 stable

All arches done, GLSA request filed.

GLSA 200712-16

Does not affect current (2008.0) release. Removing release.