From: "Adrian Bunk" <bunk@stusta.de>
To: openembedded-core@lists.openembedded.org
Subject: [OE-core][zeus][PATCH 07/19] libexif: fix CVE-2020-13114
Date: Thu, 9 Jul 2020 00:07:49 +0300 [thread overview]
Message-ID: <20200708210801.5553-7-bunk@stusta.de> (raw)
In-Reply-To: <20200708210801.5553-1-bunk@stusta.de>
From: Lee Chee Yang <chee.yang.lee@intel.com>
(From OE-Core rev: 2e497029ee00babbc50f3c1d99580230bc46155c)
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
.../libexif/libexif/CVE-2020-13114.patch | 73 +++++++++++++++++++
.../recipes-support/libexif/libexif_0.6.21.bb | 4 +-
2 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
diff --git a/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch b/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
new file mode 100644
index 0000000000..06b8b46c21
--- /dev/null
+++ b/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
@@ -0,0 +1,73 @@
+From 47f51be021f4dfd800d4ff4630659887378baa3a Mon Sep 17 00:00:00 2001
+From: Dan Fandrich <dan@coneharvesters.com>
+Date: Sat, 16 May 2020 19:32:30 +0200
+Subject: [PATCH] Add a failsafe on the maximum number of Canon MakerNote
+
+ subtags.
+
+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
+
+Upstream-Status: Backport [https://github.com/libexif/libexif/commit/e6a38a1a23ba94d139b1fa2cd4519fdcfe3c9bab]
+CVE: CVE-2020-13114
+Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
+---
+ libexif/canon/exif-mnote-data-canon.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+diff --git a/libexif/canon/exif-mnote-data-canon.c b/libexif/canon/exif-mnote-data-canon.c
+index eb53598..72fd7a3 100644
+--- a/libexif/canon/exif-mnote-data-canon.c
++++ b/libexif/canon/exif-mnote-data-canon.c
+@@ -32,6 +32,9 @@
+
+ #define DEBUG
+
++/* Total size limit to prevent abuse by DoS */
++#define FAILSAFE_SIZE_MAX 1000000L
++
+ static void
+ exif_mnote_data_canon_clear (ExifMnoteDataCanon *n)
+ {
+@@ -202,6 +205,7 @@ exif_mnote_data_canon_load (ExifMnoteData *ne,
+ ExifMnoteDataCanon *n = (ExifMnoteDataCanon *) ne;
+ ExifShort c;
+ size_t i, tcount, o, datao;
++ long failsafe_size = 0;
+
+ if (!n || !buf || !buf_size) {
+ exif_log (ne->log, EXIF_LOG_CODE_CORRUPT_DATA,
+@@ -280,6 +284,23 @@ exif_mnote_data_canon_load (ExifMnoteData *ne,
+ memcpy (n->entries[tcount].data, buf + dataofs, s);
+ }
+
++ /* Track the size of decoded tag data. A malicious file could
++ * be crafted to cause extremely large values here without
++ * tripping any buffer range checks. This is especially bad
++ * with the libexif representation of Canon MakerNotes because
++ * some arrays are turned into individual tags that the
++ * application must loop around. */
++ failsafe_size += mnote_canon_entry_count_values(&n->entries[tcount]);
++
++ if (failsafe_size > FAILSAFE_SIZE_MAX) {
++ /* Abort if the total size of the data in the tags extraordinarily large, */
++ exif_mem_free (ne->mem, n->entries[tcount].data);
++ exif_log (ne->log, EXIF_LOG_CODE_CORRUPT_DATA,
++ "ExifMnoteCanon", "Failsafe tag size overflow (%lu > %ld)",
++ failsafe_size, FAILSAFE_SIZE_MAX);
++ break;
++ }
++
+ /* Tag was successfully parsed */
+ ++tcount;
+ }
diff --git a/meta/recipes-support/libexif/libexif_0.6.21.bb b/meta/recipes-support/libexif/libexif_0.6.21.bb
index d847beab18..3f6fa32b25 100644
--- a/meta/recipes-support/libexif/libexif_0.6.21.bb
+++ b/meta/recipes-support/libexif/libexif_0.6.21.bb
@@ -7,7 +7,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=243b725d71bb5df4a1e5920b344b86ad"
SRC_URI = "${SOURCEFORGE_MIRROR}/libexif/libexif-${PV}.tar.bz2 \
file://CVE-2017-7544.patch \
file://CVE-2016-6328.patch \
- file://CVE-2018-20030.patch"
+ file://CVE-2018-20030.patch \
+ file://CVE-2020-13114.patch \
+"
SRC_URI[md5sum] = "27339b89850f28c8f1c237f233e05b27"
SRC_URI[sha256sum] = "16cdaeb62eb3e6dfab2435f7d7bccd2f37438d21c5218ec4e58efa9157d4d41a"
--
2.17.1
next prev parent reply other threads:[~2020-07-08 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 21:07 [OE-core][zeus][PATCH 01/19] python3: Upgrade 3.7.7 -> 3.7.8 Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 02/19] timezone: upgrade 2019c -> 2020a Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 03/19] sqlite: backport CVE fix Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 04/19] gcr: depends on gnupg-native Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 05/19] file: add bzip2-replacement-native to DEPENDS to fix sstate issue Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 06/19] cve-check: Run it after do_fetch Adrian Bunk
2020-07-08 21:07 ` Adrian Bunk [this message]
2020-07-08 21:07 ` [OE-core][zeus][PATCH 08/19] cve-check: include epoch in product version output Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 09/19] patchelf: Add patch to address corrupt shared library issue Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 10/19] vim: _FORTIFY_SOURCE=2 be gone Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 11/19] wpa-supplicant: remove service templates from SYSTEMD_SERVICE Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 12/19] encodings: clear postinst script Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 13/19] mtd-utils: Fix return value of ubiformat Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 14/19] bind: update 9.11.5-P4 -> 9.11.13 Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 15/19] bind: update to 9.11.19 Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 16/19] perl: Fix host specific modules problems Adrian Bunk
2020-07-08 21:07 ` [OE-core][zeus][PATCH 17/19] dbus: fix CVE-2020-12049 Adrian Bunk
2020-07-08 21:08 ` [OE-core][zeus][PATCH 18/19] perl: fix CVE-2020-10543 & CVE-2020-10878 Adrian Bunk
2020-07-08 21:08 ` [OE-core][zeus][PATCH 19/19] wpa-supplicant: Security fix CVE-2020-12695 Adrian Bunk
2020-07-08 21:32 ` ✗ patchtest: failure for "[zeus] python3: Upgrade 3.7.7 ..." and 18 more Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200708210801.5553-7-bunk@stusta.de \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox