libpng: memory leak in png_handle_eXIf() in case of CRC error

Bug #1960326 reported by Even Rouault
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libpng1.6 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Package:
ii libpng16-16:amd64 1.6.37-2 amd64 PNG library - runtime (version 1.6)

$ lsb_release -a
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

On the attached file, coming from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=44486, a memory leak can be triggered with any software using libpng. Initially found with GDAL's utilities, but can also be reproduced with pnginfo:

valgrind --leak-check=full pnginfo clusterfuzz-testcase-minimized-gdal_filesystem_fuzzer-5278568668594176
==3631607== Memcheck, a memory error detector
==3631607== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3631607== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3631607== Command: pnginfo clusterfuzz-testcase-minimized-gdal_filesystem_fuzzer-5278568668594176
==3631607==
clusterfuzz-testcase-minimized-gdal_filesystem_fuzzer-5278568668594176...
libpng warning: eXIf: CRC error
libpng error: Read Error
Could not set PNG jump value
==3631607==
==3631607== HEAP SUMMARY:
==3631607== in use at exit: 2,107,548 bytes in 5 blocks
==3631607== total heap usage: 7 allocs, 2 frees, 2,112,668 bytes allocated
==3631607==
==3631607== 4 bytes in 1 blocks are definitely lost in loss record 1 of 5
==3631607== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3631607== by 0x4886397: png_malloc_warn (in /usr/lib/x86_64-linux-gnu/libpng16.so.16.37.0)
==3631607== by 0x4895CD0: ??? (in /usr/lib/x86_64-linux-gnu/libpng16.so.16.37.0)
==3631607== by 0x488A15D: png_read_info (in /usr/lib/x86_64-linux-gnu/libpng16.so.16.37.0)
==3631607== by 0x10947C: ??? (in /usr/bin/pnginfo)
==3631607== by 0x109175: ??? (in /usr/bin/pnginfo)
==3631607== by 0x48D90B2: (below main) (libc-start.c:308)

The issue is present in libpng 1.6.37, but no longer in the master branch of https://github.com/glennrp/libpng. Through bisection I found that the commit that fixes the leak is:
https://github.com/glennrp/libpng/commit/eb6767273a4eb5d6f4ad528370d7262cf7aa220c

Revision history for this message
Even Rouault (even.rouault) wrote :
Revision history for this message
Even Rouault (even.rouault) wrote :

Turning that as a security issue, as this could cause a denial of service in a situation where a long living process would get exposed to broken images

information type: Public → Public Security
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libpng1.6 - 1.6.37-5

---------------
libpng1.6 (1.6.37-5) unstable; urgency=medium

  * debian/patches/eb6767273a4eb5d6f4ad528370d7262cf7aa220c.patch:
    - cherry-pick upstream fix for memory lieak in png_handle_eXIf function
      (LP: #1960326)

 -- Gianfranco Costamagna <email address hidden> Mon, 25 Apr 2022 19:29:57 +0200

Changed in libpng1.6 (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.