In exif_data_load_data_content of exif-data.c, there is a possible UBSAN abort due to an integer overflow. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation. References: https://source.android.com/security/bulletin/pixel/2020-06-01 https://android.googlesource.com/platform/external/libexif/+/1e187b62682ffab5003c702657d6d725b4278f16
Created libexif tracking bugs for this issue: Affects: fedora-all [bug 1847134]
Upstream commit (different from commit linked by gsuckevi which is for the Android fork): https://github.com/libexif/libexif/commit/ce03ad7ef4e8aeefce79192bf5b6f69fae396f0c
Technical summary: exif_data_load_data_content() in libexif/exif-data.c is a recursive function which is used to read tag data. It attempted to check for integer overflow using code which could itself fail due to integer overflow. This was patched in the Android fork by using UINT_MAX in the check before adding +2 to the offset variable, and in upstream by using the CHECKOVERFLOW macro which is also used elsewhere in the library. Exploitation of this vulnerability would require a crafted input file and could lead to denial-of-service due to out-of-bounds read of the data buffer.
It should also be noted that in order for this vulnerability to be exploited remotely, libexif would need to be used in a service that accepts untrusted input data from the Internet or another domain.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-0198
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4766 https://access.redhat.com/errata/RHSA-2020:4766