Changes to imlib2 in recent security update causes digikam breakage

Bug #70278 reported by Xargos on 2006-11-04
Affects Status Importance Assigned to Milestone
digikam (Ubuntu)
imlib2 (Ubuntu)
Kees Cook

Bug Description

Binary package hint: libimlib2

Last version of the library from edgy-security (1.2.1-2ubuntu1.1) is broken. Digikam no longer shows photos correctly. When you dubbleclick photo new window opens with it, but when you click "next" in it there is only black screen.

It's similar to:

Downgrading libimlib2 to 1.2.1-2ubuntu1 version fixes the problem.

Javier Jardón (jjardon) wrote :

Do you use the oficial repositories?

Changed in imlib2:
status: Unconfirmed → Needs Info

Dnia sobota 04 listopada 2006 20:20, Javier Jardón napisał:
>Do you use the oficial repositories?
>** Changed in: imlib2 (Ubuntu)
> Status: Unconfirmed => Needs Info

Of course! It's a clean new installation of Edgy only with security

As I said former library version is ok. It seems security patch broke it.

This version of package isn't in the repositories (and i haven't it)

>This version of package isn't in the repositories (and i haven't it)

Are you kidding? :P

xargos@wodka:~$ LANG=C apt-cache policy libimlib2
  Installed: 1.2.1-2ubuntu1
  Candidate: 1.2.1-2ubuntu1.1
  Version table:
     1.2.1-2ubuntu1.1 0
        500 edgy-security/main Packages
 *** 1.2.1-2ubuntu1 0
        500 cdrom://Kubuntu 6.10 _Edgy Eft_ - Release i386 (20061025.1) edgy/main Packages
        500 edgy/main Packages
        100 /var/lib/dpkg/status

Look at edgy-security!

It seems there are new bug reports connected with this one:


Ariel Faigon (ariel.faigon) wrote :

I'm seeing this bug too and I'm not even on edgy. I'm still on 6.06 LTS.

Apparently one of the recent standard security updates (via adept) broke digikam for me.

My digikam is:

$ digikam --version
Qt: 3.3.6
KDE: 3.5.3
digiKam: 0.8.2-rc1

Some images show completely black in the digikam viewer. All thumbnails in the main digikam window display ok. Only the full size images _sometime_ don't display. It is hard to say exactly when and give a "how to reproduce" recipe. Sometimes restarting and starting with a different image in the collection would make the image appear fine. Then after some back/forward navigation using either Page Up/Down keys or the arrow buttons, some images fail to display (displayed as all black).

I think the priority here should be raised.

Caroline Ford (secretlondon) wrote :

->confirmed as reported by multiple people

Changed in imlib2:
status: Needs Info → Confirmed
Caroline Ford (secretlondon) wrote :

Everybody is saying this is a recent regression caused by the security update to imlib2 which went out on 3rd November 2006. The dapper changelog is as follows:

imlib2 (1.2.1-2ubuntu0.1) dapper-security; urgency=low

  * SECURITY UPDATE: multiple overflows found in image loaders allowing
    for arbitrary code execution.
  * Add 'debian/patches/99_loader_overflows.patch': bounds check image
    sizes in argb, jpeg, lbm, png, pnm, tga, and tiff loaders.
  * References
    CVE-2006-4806, CVE-2006-4807, CVE-2006-4808, CVE-2006-4809

 -- Kees Cook <email address hidden> Fri, 3 Nov 2006 12:37:22 -0800

pointwood (jramskov) wrote :

I think it is only jpg images that is a problem. I've tested with some png and tiff images (just a quick and dirty test) and the problem didn't occur with them.

Kees Cook (kees) wrote :

Can you attach some images that do not load with imlib2? When testing with the "feh" tool, I was not able to reproduce this with any of the image types I tested.

pointwood (jramskov) wrote :

Here are 2 images that fails here. I don't think has anything to do with any specific images though.

pointwood (jramskov) wrote :

Second image. The original images was taken with a Nikon D80 and have since been resized with Imagemagick.

Kees Cook (kees) wrote :

Thanks! If I add these images to digikam with the earlier imlib2, and then view them with the new imlib2, I see the reported behavior. What's strange is that "feh" has no problem with them. I will investigate. Sorry for the breakage, I'll get it sorted out!

Kees Cook (kees) wrote :

This is for sure an imlib2 regression due to the security update, so I'm rejecting the digikam portion of the ticket.

Changed in digikam:
status: Unconfirmed → Rejected
Kees Cook (kees) wrote :

A new security release is being uploaded now which fixes the problem with JPG handling, and should be available shortly.

Changed in imlib2:
assignee: nobody → keescook
status: Confirmed → Fix Committed

>A new security release is being uploaded now which fixes the problem
>with JPG handling, and should be available shortly.
>** Changed in: imlib2 (Ubuntu)
> Assignee: (unassigned) => Kees Cook
> Status: Confirmed => Fix Committed

It works! Thx for fast reaction.

Achim Bohnet (allee) wrote :

Yes. Upgrading to libimlib2_1.2.1-2ubuntu1.2 fixes
the problem. Thx!

pointwood (jramskov) wrote :

Works here as well!

Thanks a lot!

Kees Cook (kees) wrote :
Changed in imlib2:
status: Fix Committed → Fix Released
Ariel Faigon (ariel.faigon) wrote :

Would it be possible to have a fix for the broken Dapper / 6.06 LTS too?

Toby Dickenson (toby-tarind) wrote :

> have a fix for the broken Dapper too?

This is now fixed on Dapper for me.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers