In exif_entry_get_value of exif-entry.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. References: https://source.android.com/security/bulletin/pixel/2020-06-01 https://android.googlesource.com/platform/external/libexif/+/4b7b14770c4290eaeaebadf0e99ffdfdbd8f725c
Created libexif tracking bugs for this issue: Affects: fedora-all [bug 1852491]
There is a possible small out-of-bounds read in exif_entry_get_value() in cases where entry->data is not NULL-terminated or smaller than 7 bytes in length. This is because the standard does not require the entry->data to be NULL terminated or a specific length. Since the code checked for example, strncmp ((char *)entry->data, "Minolta", 7)), there was a possibility of a limited out-of-bounds read here. The patch ensures that before strncmp() is called, the entry size is large enough to not read out-of-bounds data. Information disclosure is very limited here though for each entry because there is already a hardcoded relatively small value passed to strncmp() in the lenth parameter. This could likely also cause functional issues in cases where the strncmp() fails due to an unexpected entry->data string.
Mitigation: This flaw could be mitigated by not passing untrusted input to libexif.
Upstream fix: https://github.com/libexif/libexif/commit/f9bb9f263fb00f0603ecbefa8957cad24168cbff
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:4040 https://access.redhat.com/errata/RHSA-2020:4040
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-0182
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