Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => rverschelde

Thanks, working on it now.

I could add the patch from Fedora, but it looks like upstream is about to release 1.6.37 with the fix (as of 6 hours ago [0]), so I'll wait for this version tag. It doesn't seem critical enough to warrant going faster than upstream, who usually patch things and release updates in a timely manner.

[0] https://github.com/glennrp/libpng/issues/275#issuecomment-463466236

Status: NEW => ASSIGNED

Well I changed my mind, the new upstream maintainer doesn't seem in a hurry to make a patch release fixing a known security vulnerability, so I'll backport the patch.

Fixed in Cauldron with libpng-1.6.36-2.mga7. Update candidate for Mageia 6 below:

Advisory:
=========

Updated libpng packages fix security vulnerability

  png_image_free in png.c in libpng 1.6.0 up to 1.6.36 had a use-after-free
  because png_image_free_function is called under png_safe_execute
  (CVE-2019-7317).

References:
 - https://github.com/glennrp/libpng/issues/275
 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317


RPMs in core/updates_testing:
=============================

lib64png16_16-1.6.35-1.1.mga6
lib64png-devel-1.6.35-1.1.mga6

SRPM in core/updates_testing:
=============================

libpng-1.6.35-1.1.mga6

Whiteboard: MGA6TOO => (none)
Assignee: rverschelde => qa-bugs

mga6, x86_64

CVE-2019-7317
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12803
It appears that the reproducer needs to be run with fuzz_target_binary, a fuzzer which should be compiled with ASAN support so it is out of QA's reach.

Updated the packages.

There are 431 packages listed as depending on the library, among them blender, celestia, darktable, firefox, gif2png, gthumb, imagemagick and graphicsmagick, mplayer, virtualbox and a host of games.

Restarted firefox - all OK.
Ran a trace on darktable, which worked as expected.
$ grep libpng16 trace
open("/lib64/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libpng16.so.16.35.0", O_RDONLY) = 3

Opened and closed celestia and the trace file contained the same comments as above.

$ gif2png partlysunny.gif 
gif2png: 76 unused colors; convert with -O to remove
The resulting PNG image looked like a perfect copy of the GIF.
The trace contained "open("/lib64/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 3"

This update is OK for 64 bits.

CC: (none) => tarazed25
Whiteboard: (none) => MGA6-64-OK

It turns out that there is a documented QA procedure for this.
The comment 6 tests should be enough but we can add sam2p.
$ sam2p OrphanBlack.png tatiana.pdf
The output image can be viewed OK in okular or IM display.

Just opened some png files in gwenview... 32 bits.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK
CC: (none) => lists.jjorge

Thanks José for the i586 tests here and elsewhere.  It is always comforting to have the dual architecture OKs.  We can validate this.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0126.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED