Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I19b63acfb173b87854929a93779071e580f8bb98
Signed-off-by: Jeongmo Yang <jm80.yang@samsung.com>
|
|
This ensures that an uninitialized pointer isn't dereferenced later in
the case where the number of components (and therefore size) is 0.
This fixes the second issue reported at
https://sourceforge.net/p/libexif/bugs/125/
CVE-2020-13113
Change-Id: I93a19b0d66ef34b22a4485a492be92836711eb0a
Signed-off-by: Jeongmo Yang <jm80.yang@samsung.com>
|
|
Check for a size overflow while reading tags, which ensures that the
size is always consistent for the given components and type of the
entry, making checking further down superfluous.
This provides an alternate fix for
https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328 and for all
the MakerNote types. Likely, this makes both commits 41bd0423 and
89e5b1c1 redundant as it ensures that MakerNote entries are well-formed
when they're populated.
Some improvements on top by Marcus Meissner <marcus@jet.franken.de>
CVE-2020-13112
Change-Id: I334efda3fbf2b0bae831f74e8fa866303d0ec93b
Signed-off-by: Jeongmo Yang <jm80.yang@samsung.com>
|
|
fixes https://github.com/libexif/libexif/issues/12
|
|
|
|
|
|
|
|
Bail out if an offset runs over the datasize.
fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20065&q=libexif&can=2
|
|
|
|
* Rename 'binary' directory to 'binary-dist'
Debian invokes a 'binary' target in its build process. The presence of
the 'binary' directory breaks the automated build, as 'make' thinks the
target has already been invoked.
* Use substitution variable for 'mkdir -p' instead of hard-coding the command
|
|
|
|
A malicious file could be crafted to cause extremely large values in some
tags without tripping any buffer range checks. This is bad with the libexif
representation of Canon MakerNotes because some arrays are turned into
individual tags that the application must loop around.
The largest value I've seen for failsafe_size in a (very small) sample of valid
Canon files is <5000. The limit is set two orders of magnitude larger to avoid
tripping up falsely in case some models use much larger values.
Patch from Google.
CVE-2020-13114
|
|
If too large an indent is given, a local buffer will overflow. This
can't happen when called through exif_data_dump (which is likely the
most common case) and since they are documented as being for diagnostic
purposes only, this shouldn't pose too big a security risk in the wild.
Reported-by: jonnygrant.
(not exploitable by malicious data)
|
|
This ensures that an uninitialized pointer isn't dereferenced later in
the case where the number of components (and therefore size) is 0.
This fixes the second issue reported at
https://sourceforge.net/p/libexif/bugs/125/
CVE-2020-13113
|
|
Check for a size overflow while reading tags, which ensures that the
size is always consistent for the given components and type of the
entry, making checking further down superfluous.
This provides an alternate fix for
https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328 and for all
the MakerNote types. Likely, this makes both commits 41bd0423 and
89e5b1c1 redundant as it ensures that MakerNote entries are well-formed
when they're populated.
Some improvements on top by Marcus Meissner <marcus@jet.franken.de>
CVE-2020-13112
|
|
|
|
fixes https://github.com/libexif/libexif/issues/41
|
|
Make sure the number of bytes being copied from doesn't exceed the
source buffer size.
From Android repo:
https://android.googlesource.com/platform/external/libexif/+/0335ffc17f9b9a4831c242bb08ea92f605fde7a6%5E%21/#F0
Test: testPocBug_148705132
Bug: 148705132
fixes https://github.com/libexif/libexif/issues/42
|
|
|
|
Travis defaults to xenial these days, so some builds were redundant.
Add gcc9, clang9 and clang10 builds. Switch the sanitize build to
clang10. Add a PPC build.
|
|
|
|
dividing by zero
|
|
According to DC-08-2012
FlashPixVersion shoule be FlashpixVersion
|
|
undefined behaviour : cannot be represented in type 'int'
|
|
(weird integer promotion, a unsigned char will be first tried to be promoted to "int" apparently,
so we need to cast it to avoid implicit behaviour)
fixes https://github.com/libexif/libexif/issues/20
|
|
avoid the use of unsafe integer overflow checking constructs (unsigned integer operations cannot overflow, so "u1 + u2 > u1" can be optimized away)
check for the actual sizes, which should also handle the overflows
document other places google patched, but do not seem relevant due to other restrictions
fixes https://github.com/libexif/libexif/issues/26
|
|
Upstream support for 10.4 ended a year ago, and it looks like the image
is now gone, too.
[skip ci]
|
|
Reported by Thorsten Otto. Fixes #22.
|
|
While parsing EXIF_TAG_FOCAL_LENGTH it was possible to read 8 bytes past
the end of a heap buffer. This was detected by the OSS Fuzz project.
Patch from Google.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7344 and
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14543
|
|
|
|
If more commits are submitted to master between the time of triggering
the first Cirrus build and the time the final build gets started, the
desired commit is no longer at HEAD and the build will error out.
[skip ci]
|
|
|
|
Also, select the images using image_family to get the latest snapshots
automatically.
[skip ci]
|
|
This brings the file under the same license as the rest of the project
by default, and eliminates the ambiguous (but well-intentioned) license
under which it was supplied.
[skip ci]
|
|
This will cause any compiler warnings to be treated as errors and fail
the CI build. A couple of warnings are grandfathered in until they are
fixed in the code.
The -Werror switch can't be added to the CFLAGS on the configure command
because it causes some autoconf tests to fail. Instead, it's appended to
the existing flags at make time.
|
|
|
|
Something in the Travis build environment has changed recently to cause
failmalloc runs to crash while exiting due to a NULL pointer dereference
in the coverage writing code. This fix causes failmalloc to
automatically disable itself once main() exits so subsequent memory
requests always succeed. Since the application (and library) have no
control over what happens during exit cleanup anyway, this does not
affect its functionality.
|
|
This fixes the clang6 build since the Trusty environment has started
complaining that libjsoncpp0 doesn't exist when trying to install
clang-6.0.
|
|
Extended test-null.c to verify them.
Fixes #19 (reported by jonnygrant@).
|
|
|
|
|
|
Also, added docs for a few functions that were missing them.
Fixes issue #18.
[skip ci]
|
|
This is the same change as the previous one but for the MakerNotes.
Patch from Google.
|
|
By leaving them as double, it avoids undefined behaviour when the values
are out of the range of an int. This also has the side effect of
rounding some values to the nearest integer, improving display accuracy.
Patch from Google.
|
|
|
|
A sanity check on entry to the block ensures a minimum buffer size, so a few
other checks were redundant and could actually be removed. This improves
on commit a0c04d9c.
Fixes https://sourceforge.net/p/libexif/bugs/132/ found by the Google
Autofuzz project. Patch from Google.
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8884
|
|
The value of 1 caused problems when more than one commit was pushed but
the most recent commit(s) had a "skip ci" note. Travis would try to
build from a prior new commit without the tag but it would fail because
only the most recent was available.
|
|
[skip ci]
|
|
[skip ci]
|