Fix CVE issues and add new libav recipe

PATCH In review Kai Kang 7 participants 16 messages May 28, 2015 – May 30, 2015

lore

Share & tools

lore

Kai Kang

author

2015-05-28 01:32 UTC #0 lore raw

cover Fix CVE issues and add new libav recipe

* Fix CVE issues for severial packages
* Upgrade libav 9.61 --> 9.18
* Add recipe for libav series 11

Build world for x86-64 and qemuarm are fine except some textrel warnings for qemuarm. Should I open new defects that?

--Kai

The following changes since commit a431e5aa572358ba61cf3c9e501f830263bdcd3d:

bitbake: data: Make expandKeys deterministic (2015-05-27 17:48:06 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib kangkai/CVEs
http://git.yoctoproject.org/cgit.cgi//log/?h=kangkai/CVEs

Kai Kang (5):
gpgme: fix CVE-2014-3564
grep: fix CVE-2015-1345
qt4: fix CVE issues
libav: upgrade to 9.18
libav: add recipe for 11 release series

 .../grep/grep/grep-fix-CVE-2015-1345.patch         | 154 +++++++++++++++++++++
 meta/recipes-extended/grep/grep_2.21.bb            |   3 +-
 meta/recipes-multimedia/libav/libav.inc            |   2 -
 .../libav/libav/libav-fix-CVE-2014-9676.patch      |  98 +++++++++++++
 meta/recipes-multimedia/libav/libav_11.3.bb        |   4 +
 meta/recipes-multimedia/libav/libav_9.16.bb        |   4 -
 meta/recipes-multimedia/libav/libav_9.18.bb        |   6 +
 meta/recipes-qt/qt4/qt4-4.8.6.inc                  |   2 +
 ...Fixes-crash-in-bmp-and-ico-image-decoding.patch |  71 ++++++++++
 .../0036-Fixes-crash-in-gif-image-decoder.patch    |  39 ++++++
 .../gpgme-1.4.3/gpgme-fix-CVE-2014-3564.patch      |  56 ++++++++
 meta/recipes-support/gpgme/gpgme_1.4.3.bb          |   4 +-
 12 files changed, 435 insertions(+), 8 deletions(-)
 create mode 100644 meta/recipes-extended/grep/grep/grep-fix-CVE-2015-1345.patch
 create mode 100644 meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch
 create mode 100644 meta/recipes-multimedia/libav/libav_11.3.bb
 delete mode 100644 meta/recipes-multimedia/libav/libav_9.16.bb
 create mode 100644 meta/recipes-multimedia/libav/libav_9.18.bb
 create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/0035-Fixes-crash-in-bmp-and-ico-image-decoding.patch
 create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/0036-Fixes-crash-in-gif-image-decoder.patch
 create mode 100644 meta/recipes-support/gpgme/gpgme-1.4.3/gpgme-fix-CVE-2014-3564.patch

Signature · 1 line

1.9.1

Kai Kang

author

2015-05-28 01:32 UTC #1 lore raw

PATCH 1/5 gpgme: fix CVE-2014-3564

Backport patch to fix CVE-2014-3564.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=2cbd76f

Signed-off-by Kai Kang <[email protected]>

---
 .../gpgme-1.4.3/gpgme-fix-CVE-2014-3564.patch      | 56 ++++++++++++++++++++++
 meta/recipes-support/gpgme/gpgme_1.4.3.bb          |  4 +-
 2 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/gpgme/gpgme-1.4.3/gpgme-fix-CVE-2014-3564.patch

meta/recipes-support/gpgme/gpgme-1.4.3/gpgme-fix-CVE-2014-3564.patch new file +56 -0

new file mode 100644
index 0000000..c728f58
@@ -0,0 +1,56 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2014-3564.
+
+http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=2cbd76f7911fc215845e89b50d6af5ff4a83dd77
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From 2cbd76f7911fc215845e89b50d6af5ff4a83dd77 Mon Sep 17 00:00:00 2001
+From: Werner Koch <[email protected]>
+Date: Wed, 30 Jul 2014 11:04:55 +0200
+Subject: [PATCH 1/1] Fix possible realloc overflow for gpgsm and uiserver
+ engines.
+
+After a realloc (realloc is also used for initial alloc) the allocated
+size if the buffer is not correctly recorded.  Thus an overflow can be
+introduced by receiving data with different line lengths in a specific
+order.  This is not easy exploitable because libassuan constructs the
+line.  However a crash has been reported and thus it might be possible
+to constructs an exploit.
+
+CVE-id: CVE-2014-3564
+Reported-by: TomÃ¡Å¡ Trnka
+---
+ src/engine-gpgsm.c    | 2 +-
+ src/engine-uiserver.c | 2 +-
+ 3 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c
+index 8ec1598..3a83757 100644
+--- a/src/engine-gpgsm.c
++++ b/src/engine-gpgsm.c
+@@ -836,7 +836,7 @@ status_handler (void *opaque, int fd)
+ 	      else
+ 		{
+ 		  *aline = newline;
+-		  gpgsm->colon.attic.linesize += linelen + 1;
++		  gpgsm->colon.attic.linesize = *alinelen + linelen + 1;
+ 		}
+ 	    }
+ 	  if (!err)
+diff --git a/src/engine-uiserver.c b/src/engine-uiserver.c
+index 2738c36..a7184b7 100644
+--- a/src/engine-uiserver.c
++++ b/src/engine-uiserver.c
+@@ -698,7 +698,7 @@ status_handler (void *opaque, int fd)
+ 	      else
+ 		{
+ 		  *aline = newline;
+-		  uiserver->colon.attic.linesize += linelen + 1;
++		  uiserver->colon.attic.linesize = *alinelen + linelen + 1;
+ 		}
+ 	    }
+ 	  if (!err)
+-- 
+2.1.4

meta/recipes-support/gpgme/gpgme_1.4.3.bb +3 -1

index cba3589..f804578 100644
@@ -11,7 +11,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 SRC_URI = "ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-${PV}.tar.bz2 \
            file://gpgme.pc \
-           file://pkgconfig.patch"
+           file://pkgconfig.patch \
+           file://gpgme-fix-CVE-2014-3564.patch \
+          "
 
 SRC_URI[md5sum] = "334e524cffa8af4e2f43ae8afe585672"
 SRC_URI[sha256sum] = "2d1cc12411753752d9c5b9037e6fd3fd363517af720154768cc7b46b60120496"

Signature · 1 line

1.9.1

Kai Kang

author

2015-05-28 01:32 UTC #2 lore raw

PATCH 2/5 grep: fix CVE-2015-1345

In reply to Kai Kang

Backport patch to fix CVE-2015-1345. The issue was introduced with v2.18-90-g73893ff, and version 2.5.1a is not affected.

Replace tab with spaces in SRC_URI as well.

Signed-off-by Kai Kang <[email protected]>

---
 .../grep/grep/grep-fix-CVE-2015-1345.patch         | 154 +++++++++++++++++++++
 meta/recipes-extended/grep/grep_2.21.bb            |   3 +-
 2 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/grep/grep/grep-fix-CVE-2015-1345.patch

meta/recipes-extended/grep/grep/grep-fix-CVE-2015-1345.patch new file +154 -0

new file mode 100644
index 0000000..e88a988
@@ -0,0 +1,154 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2015-1345.
+http://git.savannah.gnu.org/cgit/grep.git/commit/?id=83a95bd
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From 83a95bd8c8561875b948cadd417c653dbe7ef2e2 Mon Sep 17 00:00:00 2001
+From: Yuliy Pisetsky <[email protected]>
+Date: Thu, 1 Jan 2015 15:36:55 -0800
+Subject: [PATCH] grep -F: fix a heap buffer (read) overrun
+
+grep's read buffer is often filled to its full size, except when
+reading the final buffer of a file.  In that case, the number of
+bytes read may be far less than the size of the buffer.  However, for
+certain unusual pattern/text combinations, grep -F would mistakenly
+examine bytes in that uninitialized region of memory when searching
+for a match.  With carefully chosen inputs, one can cause grep -F to
+read beyond the end of that buffer altogether.  This problem arose via
+commit v2.18-90-g73893ff with the introduction of a more efficient
+heuristic using what is now the memchr_kwset function. The use of
+that function in bmexec_trans could leave TP much larger than EP,
+and the subsequent call to bm_delta2_search would mistakenly access
+beyond end of the main input read buffer.
+
+* src/kwset.c (bmexec_trans): When TP reaches or exceeds EP,
+do not call bm_delta2_search.
+* tests/kwset-abuse: New file.
+* tests/Makefile.am (TESTS): Add it.
+* THANKS.in: Update.
+* NEWS (Bug fixes): Mention it.
+
+Prior to this patch, this command would trigger a UMR:
+
+  printf %0360db 0 | valgrind src/grep -F $(printf %019dXb 0)
+
+  Use of uninitialised value of size 8
+     at 0x4142BE: bmexec_trans (kwset.c:657)
+     by 0x4143CA: bmexec (kwset.c:678)
+     by 0x414973: kwsexec (kwset.c:848)
+     by 0x414DC4: Fexecute (kwsearch.c:128)
+     by 0x404E2E: grepbuf (grep.c:1238)
+     by 0x4054BF: grep (grep.c:1417)
+     by 0x405CEB: grepdesc (grep.c:1645)
+     by 0x405EC1: grep_command_line_arg (grep.c:1692)
+     by 0x4077D4: main (grep.c:2570)
+
+See the accompanying test for how to trigger the heap buffer overrun.
+
+Thanks to Nima Aghdaii for testing and finding numerous
+ways to break early iterations of this patch.
+---
+ NEWS              |  5 +++++
+ THANKS.in         |  1 +
+ src/kwset.c       |  2 ++
+ tests/Makefile.am |  1 +
+ tests/kwset-abuse | 32 ++++++++++++++++++++++++++++++++
+ 5 files changed, 41 insertions(+)
+ create mode 100755 tests/kwset-abuse
+
+diff --git a/NEWS b/NEWS
+index 975440d..3835d8d 100644
+--- a/NEWS
++++ b/NEWS
+@@ -2,6 +2,11 @@ GNU grep NEWS                                    -*- outline -*-
+ 
+ * Noteworthy changes in release ?.? (????-??-??) [?]
+ 
++** Bug fixes
++
++  grep no longer reads from uninitialized memory or from beyond the end
++  of the heap-allocated input buffer.
++
+ 
+ * Noteworthy changes in release 2.21 (2014-11-23) [stable]
+ 
+diff --git a/THANKS.in b/THANKS.in
+index aeaf516..624478d 100644
+--- a/THANKS.in
++++ b/THANKS.in
+@@ -62,6 +62,7 @@ Michael Aichlmayr                   [email protected]
+ Miles Bader                         [email protected]
+ Mirraz Mirraz                       [email protected]
+ Nelson H. F. Beebe                  [email protected]
++Nima Aghdaii                        [email protected]
+ Olaf Kirch                          [email protected]
+ Paul Kimoto                         [email protected]
+ Péter Radics                        [email protected]
+diff --git a/src/kwset.c b/src/kwset.c
+index 4003c8d..376f7c3 100644
+--- a/src/kwset.c
++++ b/src/kwset.c
+@@ -643,6 +643,8 @@ bmexec_trans (kwset_t kwset, char const *text, size_t size)
+                     if (! tp)
+                       return -1;
+                     tp++;
++                    if (ep <= tp)
++                      break;
+                   }
+               }
+           }
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 2cba2cd..0508cd2 100644
+--- a/tests/Makefile.am
++++ b/tests/Makefile.am
+@@ -75,6 +75,7 @@ TESTS =						\
+   inconsistent-range				\
+   invalid-multibyte-infloop			\
+   khadafy					\
++  kwset-abuse					\
+   long-line-vs-2GiB-read			\
+   match-lines					\
+   max-count-overread				\
+diff --git a/tests/kwset-abuse b/tests/kwset-abuse
+new file mode 100755
+index 0000000..6d8ec0c
+--- /dev/null
++++ b/tests/kwset-abuse
+@@ -0,0 +1,32 @@
++#! /bin/sh
++# Evoke a segfault in a hard-to-reach code path of kwset.c.
++# This bug affected grep versions 2.19 through 2.21.
++#
++# Copyright (C) 2015 Free Software Foundation, Inc.
++#
++# This program is free software: you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation, either version 3 of the License, or
++# (at your option) any later version.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see <http://www.gnu.org/licenses/>.
++
++. "${srcdir=.}/init.sh"; path_prepend_ ../src
++
++fail=0
++
++# This test case chooses a haystack of size 260,000, since prodding
++# with gdb showed a reallocation slightly larger than that in fillbuf.
++# To reach the buggy code, the needle must have length < 1/11 that of
++# the haystack, and 10,000 is a nice round number that fits the bill.
++printf '%0260000dXy\n' 0 | grep -F $(printf %010000dy 0)
++
++test $? = 1 || fail=1
++
++Exit $fail
+-- 
+2.4.1
+

meta/recipes-extended/grep/grep_2.21.bb +2 -1

index 1c5f778..3661098 100644
@@ -7,7 +7,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=8006d9c814277c1bfc4ca22af94b59ee"
 
 SRC_URI = "${GNU_MIRROR}/grep/grep-${PV}.tar.xz \
            file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
-	   "
+           file://grep-fix-CVE-2015-1345.patch \
+          "
 
 SRC_URI[md5sum] = "43c48064d6409862b8a850db83c8038a"
 SRC_URI[sha256sum] = "5244a11c00dee8e7e5e714b9aaa053ac6cbfa27e104abee20d3c778e4bb0e5de"

Signature · 1 line

1.9.1

Kai Kang

author

2015-05-28 01:32 UTC #3 lore raw

PATCH 3/5 qt4: fix CVE issues

In reply to Kai Kang

Backport patches to fix qt4 CVE issues:

* CVE-2015-1858
* CVE-2015-1859
* CVE-2015-1860

Signed-off-by Kai Kang <[email protected]>

---
 meta/recipes-qt/qt4/qt4-4.8.6.inc                  |  2 +
 ...Fixes-crash-in-bmp-and-ico-image-decoding.patch | 71 ++++++++++++++++++++++
 .../0036-Fixes-crash-in-gif-image-decoder.patch    | 39 ++++++++++++
 3 files changed, 112 insertions(+)
 create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/0035-Fixes-crash-in-bmp-and-ico-image-decoding.patch
 create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/0036-Fixes-crash-in-gif-image-decoder.patch

meta/recipes-qt/qt4/qt4-4.8.6.inc +2 -0

index 0cb7f80..4fe26af 100644
@@ -27,6 +27,8 @@ SRC_URI = "http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
            file://0031-aarch64_arm64_mkspecs.patch \
            file://0032-aarch64_add_header.patch \
            file://0034-Fix-a-division-by-zero-when-processing-malformed-BMP.patch \
+           file://0035-Fixes-crash-in-bmp-and-ico-image-decoding.patch \
+           file://0036-Fixes-crash-in-gif-image-decoder.patch \
            file://Fix-QWSLock-invalid-argument-logs.patch \
            file://add_check_for_aarch64_32.patch \
            file://g++.conf \

meta/recipes-qt/qt4/qt4-4.8.6/0035-Fixes-crash-in-bmp-and-ico-image-decoding.patch new file +71 -0

71 lines not on this page · raw message

meta/recipes-qt/qt4/qt4-4.8.6/0036-Fixes-crash-in-gif-image-decoder.patch new file +39 -0

new file mode 100644
index 0000000..c1baf0e
@@ -0,0 +1,39 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2015-1860
+
+http://code.qt.io/cgit/qt/qt.git/commit/?id=9f2425a
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From a1cf194c54be57d6ab55dfd26b9562a60532208e Mon Sep 17 00:00:00 2001
+From: Eirik Aavitsland <[email protected]>
+Date: Wed, 11 Mar 2015 09:00:41 +0100
+Subject: [PATCH] Fixes crash in gif image decoder
+
+Fuzzing test revealed that for certain malformed gif files,
+qgifhandler would segfault.
+
+Change-Id: I5bb6f60e1c61849e0d8c735edc3869945e5331c1
+(cherry picked from qtbase/ea2c5417fcd374302f5019e67f72af5facbd29f6)
+Reviewed-by: Richard J. Moore <[email protected]>
+---
+ src/gui/image/qgifhandler.cpp | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/gui/image/qgifhandler.cpp b/src/gui/image/qgifhandler.cpp
+index 5199dd3..49aa2a6 100644
+--- a/src/gui/image/qgifhandler.cpp
++++ b/src/gui/image/qgifhandler.cpp
+@@ -944,6 +944,8 @@ void QGIFFormat::fillRect(QImage *image, int col, int row, int w, int h, QRgb co
+ 
+ void QGIFFormat::nextY(unsigned char *bits, int bpl)
+ {
++    if (out_of_bounds)
++        return;
+     int my;
+     switch (interlace) {
+     case 0: // Non-interlaced
+-- 
+2.4.1
+

Signature · 1 line

1.9.1

Alexander Kanavin

2015-05-28 13:13 UTC #4 lore raw

Re: [PATCH 3/5] qt4: fix CVE issues

Quoted 5 lines · Kai Kang

Backport patches to fix qt4 CVE issues:
* CVE-2015-1858
* CVE-2015-1859
* CVE-2015-1860

Qt 4.8.7 is out and (I presume) it has all of those fixes. Why not update to that version instead?

Alex

Kang Kai

author

2015-05-29 01:26 UTC #5 lore raw

Re: [PATCH 3/5] qt4: fix CVE issues

Quoted 8 lines · Alexander Kanavin

Quoted 5 lines · Kai Kang
Backport patches to fix qt4 CVE issues:
* CVE-2015-1858
* CVE-2015-1859
* CVE-2015-1860
Qt 4.8.7 is out and (I presume) it has all of those fixes. Why not update to that version instead?

Qt 4.8.7 is released on May 25 and I didn't see it when I made the patches. I'll update it.

Regards,
Kai

Quoted 4 lines

Alex

Signature · 2 lines

Regards,
Neil | Kai Kang

Kai Kang

author

2015-05-28 01:32 UTC #6 lore raw

PATCH 4/5 libav: upgrade to 9.18

In reply to Kai Kang

Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.

Signed-off-by Kai Kang <[email protected]>

---
 meta/recipes-multimedia/libav/libav.inc            |  2 -
 .../libav/libav/libav-fix-CVE-2014-9676.patch      | 98 ++++++++++++++++++++++
 meta/recipes-multimedia/libav/libav_9.16.bb        |  4 -
 meta/recipes-multimedia/libav/libav_9.18.bb        |  6 ++
 4 files changed, 104 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch
 delete mode 100644 meta/recipes-multimedia/libav/libav_9.16.bb
 create mode 100644 meta/recipes-multimedia/libav/libav_9.18.bb

meta/recipes-multimedia/libav/libav.inc +0 -2

index cac836f..6ef273b 100644
@@ -24,8 +24,6 @@ ARM_INSTRUCTION_SET = "arm"
 
 DEPENDS = "alsa-lib zlib libogg yasm-native"
 
-INC_PR = "r8"
-
 inherit autotools pkgconfig
 
 B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"

meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch new file +98 -0

98 lines not on this page · raw message

meta/recipes-multimedia/libav/libav_9.16.bb deleted +0 -4

deleted file mode 100644
index 79ff3f8..0000000
@@ -1,4 +0,0 @@
-require libav.inc
-
-SRC_URI[md5sum] = "7b44b75cec24b8e7545e5029e76917e0"
-SRC_URI[sha256sum] = "ca846473b0b8ed8e3404c52e5e92df6d35cb5fa487eec498525de3ffda4367a0"

meta/recipes-multimedia/libav/libav_9.18.bb new file +6 -0

new file mode 100644
index 0000000..210a649
@@ -0,0 +1,6 @@
+require libav.inc
+
+SRC_URI[md5sum] = "75e838068a75fb88e1b4ea0546bc16f0"
+SRC_URI[sha256sum] = "0875e835da683eef1a7bac75e1884634194149d7479d1538ba9fbe1614d066d7"
+
+SRC_URI += "file://libav-fix-CVE-2014-9676.patch"

Signature · 1 line

1.9.1

Jussi Kukkonen

2015-05-28 07:14 UTC #7 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 2 lines · Kai Kang

Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.

I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?

I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.

Jussi

Quoted 158 lines

Signed-off-by Kai Kang <[email protected]>

---
 meta/recipes-multimedia/libav/libav.inc            |  2 -
 .../libav/libav/libav-fix-CVE-2014-9676.patch      | 98 ++++++++++++++++++++++
 meta/recipes-multimedia/libav/libav_9.16.bb        |  4 -
 meta/recipes-multimedia/libav/libav_9.18.bb        |  6 ++
 4 files changed, 104 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch
 delete mode 100644 meta/recipes-multimedia/libav/libav_9.16.bb
 create mode 100644 meta/recipes-multimedia/libav/libav_9.18.bb

meta/recipes-multimedia/libav/libav.inc +0 -2

index cac836f..6ef273b 100644
@@ -24,8 +24,6 @@ ARM_INSTRUCTION_SET = "arm"
 
 DEPENDS = "alsa-lib zlib libogg yasm-native"
 
-INC_PR = "r8"
-
 inherit autotools pkgconfig
 
 B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"

meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch new file +98 -0

new file mode 100644
index 0000000..1e31caa
@@ -0,0 +1,98 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2014-9676.
+
+https://security-tracker.debian.org/tracker/CVE-2014-9676
+https://git.libav.org/?p=libav.git;a=commit;h=b3f04657368a32a9903406395f865e230b1de348
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From b3f04657368a32a9903406395f865e230b1de348 Mon Sep 17 00:00:00 2001
+From: Luca Barbato <[email protected]>
+Date: Mon, 5 Jan 2015 10:40:41 +0100
+Subject: [PATCH] segment: Fix the failure paths
+
+A failure in segment_end() or segment_start() would lead to freeing
+a dangling pointer and in general further calls to seg_write_packet()
+or to seg_write_trailer() would have the same faulty behaviour.
+
+CC: [email protected]
+Reported-By: [email protected]
+---
+ libavformat/segment.c | 32 ++++++++++++++++++++------------
+ 1 file changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/libavformat/segment.c b/libavformat/segment.c
+index 52da6b9..bcfd1f9 100644
+--- a/libavformat/segment.c
++++ b/libavformat/segment.c
+@@ -184,6 +184,13 @@ static void close_null_ctx(AVIOContext *pb)
+     av_free(pb);
+ }
+
++static void seg_free_context(SegmentContext *seg)
++{
++    avio_closep(&seg->pb);
++    avformat_free_context(seg->avf);
++    seg->avf = NULL;
++}
++
+ static int seg_write_header(AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+@@ -265,12 +272,9 @@ static int seg_write_header(AVFormatContext *s)
+     }
+
+ fail:
+-    if (ret) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        if (seg->avf)
+-            avformat_free_context(seg->avf);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
++
+     return ret;
+ }
+
+@@ -282,6 +286,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     int64_t end_pts = seg->recording_time * seg->number;
+     int ret, can_split = 1;
+
++    if (!oc)
++        return AVERROR(EINVAL);
++
+     if (seg->has_video) {
+         can_split = st->codec->codec_type == AVMEDIA_TYPE_VIDEO &&
+                     pkt->flags & AV_PKT_FLAG_KEY;
+@@ -322,11 +329,8 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     ret = ff_write_chained(oc, pkt->stream_index, pkt, s);
+
+ fail:
+-    if (ret < 0) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        avformat_free_context(oc);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
+
+     return ret;
+ }
+@@ -335,7 +339,11 @@ static int seg_write_trailer(struct AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+     AVFormatContext *oc = seg->avf;
+-    int ret;
++    int ret = 0;
++
++    if (!oc)
++        goto fail;
++
+     if (!seg->write_header_trailer) {
+         if ((ret = segment_end(oc, 0)) < 0)
+             goto fail;
+--
+2.4.1.314.g9532ead
+

meta/recipes-multimedia/libav/libav_9.16.bb deleted +0 -4

deleted file mode 100644
index 79ff3f8..0000000
@@ -1,4 +0,0 @@
-require libav.inc
-
-SRC_URI[md5sum] = "7b44b75cec24b8e7545e5029e76917e0"
-SRC_URI[sha256sum] = "ca846473b0b8ed8e3404c52e5e92df6d35cb5fa487eec498525de3ffda4367a0"

meta/recipes-multimedia/libav/libav_9.18.bb new file +6 -1

new file mode 100644
index 0000000..210a649
@@ -0,0 +1,6 @@
+require libav.inc
+
+SRC_URI[md5sum] = "75e838068a75fb88e1b4ea0546bc16f0"
+SRC_URI[sha256sum] = "0875e835da683eef1a7bac75e1884634194149d7479d1538ba9fbe1614d066d7"
+
+SRC_URI += "file://libav-fix-CVE-2014-9676.patch"
--

1.9.1

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Kang Kai

author

2015-05-28 08:18 UTC #8 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 10 lines · Jussi Kukkonen

Quoted 2 lines · Kai Kang
Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.
I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?
I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.

The original thought is just in case someone may want libav 9. According to release log, series 11 is

"Libav 11 is API-, but not ABI-compatible with the previous major release."

So it is ok for us to use libav 11 as default. libav 9 recipe could be removed if no one opposes.

Ref:
https://libav.org/releases/libav-11.3.release

--Kai

Quoted 162 lines

Jussi

Quoted 158 lines

Signed-off-by Kai Kang <[email protected]>

---
  meta/recipes-multimedia/libav/libav.inc            |  2 -
  .../libav/libav/libav-fix-CVE-2014-9676.patch      | 98 ++++++++++++++++++++++
  meta/recipes-multimedia/libav/libav_9.16.bb        |  4 -
  meta/recipes-multimedia/libav/libav_9.18.bb        |  6 ++
  4 files changed, 104 insertions(+), 6 deletions(-)

create mode 100644 meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch delete mode 100644 meta/recipes-multimedia/libav/libav_9.16.bb
create mode 100644 meta/recipes-multimedia/libav/libav_9.18.bb

meta/recipes-multimedia/libav/libav.inc +0 -2

index cac836f..6ef273b 100644
@@ -24,8 +24,6 @@ ARM_INSTRUCTION_SET = "arm"
 
  DEPENDS = "alsa-lib zlib libogg yasm-native"
 
-INC_PR = "r8"
-
  inherit autotools pkgconfig
 
  B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"

meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch new file +98 -0

new file mode 100644
index 0000000..1e31caa
@@ -0,0 +1,98 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2014-9676.
+
+https://security-tracker.debian.org/tracker/CVE-2014-9676
+https://git.libav.org/?p=libav.git;a=commit;h=b3f04657368a32a9903406395f865e230b1de348
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From b3f04657368a32a9903406395f865e230b1de348 Mon Sep 17 00:00:00 2001
+From: Luca Barbato <[email protected]>
+Date: Mon, 5 Jan 2015 10:40:41 +0100
+Subject: [PATCH] segment: Fix the failure paths
+
+A failure in segment_end() or segment_start() would lead to freeing
+a dangling pointer and in general further calls to seg_write_packet()
+or to seg_write_trailer() would have the same faulty behaviour.
+
+CC: [email protected]
+Reported-By: [email protected]
+---
+ libavformat/segment.c | 32 ++++++++++++++++++++------------
+ 1 file changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/libavformat/segment.c b/libavformat/segment.c
+index 52da6b9..bcfd1f9 100644
+--- a/libavformat/segment.c
++++ b/libavformat/segment.c
+@@ -184,6 +184,13 @@ static void close_null_ctx(AVIOContext *pb)
+     av_free(pb);
+ }
+
++static void seg_free_context(SegmentContext *seg)
++{
++    avio_closep(&seg->pb);
++    avformat_free_context(seg->avf);
++    seg->avf = NULL;
++}
++
+ static int seg_write_header(AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+@@ -265,12 +272,9 @@ static int seg_write_header(AVFormatContext *s)
+     }
+
+ fail:
+-    if (ret) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        if (seg->avf)
+-            avformat_free_context(seg->avf);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
++
+     return ret;
+ }
+
+@@ -282,6 +286,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     int64_t end_pts = seg->recording_time * seg->number;
+     int ret, can_split = 1;
+
++    if (!oc)
++        return AVERROR(EINVAL);
++
+     if (seg->has_video) {
+         can_split = st->codec->codec_type == AVMEDIA_TYPE_VIDEO &&
+                     pkt->flags & AV_PKT_FLAG_KEY;
+@@ -322,11 +329,8 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     ret = ff_write_chained(oc, pkt->stream_index, pkt, s);
+
+ fail:
+-    if (ret < 0) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        avformat_free_context(oc);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
+
+     return ret;
+ }
+@@ -335,7 +339,11 @@ static int seg_write_trailer(struct AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+     AVFormatContext *oc = seg->avf;
+-    int ret;
++    int ret = 0;
++
++    if (!oc)
++        goto fail;
++
+     if (!seg->write_header_trailer) {
+         if ((ret = segment_end(oc, 0)) < 0)
+             goto fail;
+--
+2.4.1.314.g9532ead
+

meta/recipes-multimedia/libav/libav_9.16.bb deleted +0 -4

deleted file mode 100644
index 79ff3f8..0000000
@@ -1,4 +0,0 @@
-require libav.inc
-
-SRC_URI[md5sum] = "7b44b75cec24b8e7545e5029e76917e0"
-SRC_URI[sha256sum] = "ca846473b0b8ed8e3404c52e5e92df6d35cb5fa487eec498525de3ffda4367a0"

meta/recipes-multimedia/libav/libav_9.18.bb new file +6 -1

new file mode 100644
index 0000000..210a649
@@ -0,0 +1,6 @@
+require libav.inc
+
+SRC_URI[md5sum] = "75e838068a75fb88e1b4ea0546bc16f0"
+SRC_URI[sha256sum] = "0875e835da683eef1a7bac75e1884634194149d7479d1538ba9fbe1614d066d7"
+
+SRC_URI += "file://libav-fix-CVE-2014-9676.patch"
--

1.9.1

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 2 lines

Regards,
Neil | Kai Kang

Jussi Kukkonen

2015-05-28 08:38 UTC #9 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 16 lines · Kang Kai

Quoted 6 lines · Jussi Kukkonen
Quoted 3 lines · Kai Kang
Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.
Quoted 7 lines
I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?
I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.

Quoted 6 lines

The original thought is just in case someone may want libav 9. According to release log, series 11
is
"Libav 11 is API-, but not ABI-compatible with the previous major release."

For full disclosure, libav 10 is not API-compatible with 9: the differences aren't big but will certainly require changes in some applications. Still, I haven't seen anything that would necessitate keeping two versions.

- Jussi

Quoted 2 lines

So it is ok for us to use libav 11 as default. libav 9 recipe could be removed if no one opposes.

Martin Jansa

2015-05-28 08:46 UTC #10 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

In reply to Kang Kai

Quoted 16 lines · Kang Kai

Quoted 10 lines · Jussi Kukkonen
Quoted 2 lines · Kai Kang
Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.
I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?
I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.
The original thought is just in case someone may want libav 9. According to release log, series 11
is

Quoted 7 lines

"Libav 11 is API-, but not ABI-compatible with the previous major release."
So it is ok for us to use libav 11 as default. libav 9 recipe could be removed if no one opposes.
Ref:
https://libav.org/releases/libav-11.3.release

Does libav-11 show the same textrel issues? If it's fixed there I'm in favor of dropping libav-9.

from last world build:
gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/gstreamer1.0-libav/1.4.5-r0/packages-split/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/i586-oe-linux/gstreamer1.0-libav/1.4.5-r0/packages-split/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/libav/9.16-r0/packages-split/libavcodec/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavcodec/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavdevice/usr/lib/libavdevice.so.53.2.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavfilter/usr/lib/libavfilter.so.3.3.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavformat/usr/lib/libavformat.so.54.20.4' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavresample/usr/lib/libavresample.so.1.0.1' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavutil/usr/lib/libavutil.so.52.3.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libswscale/usr/lib/libswscale.so.2.1.1' has relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary '/tmp/work/armv5te-oe-linux-gnueabi/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary '/tmp/work/i586-oe-linux/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel]

Quoted 170 lines

Quoted 159 lines

Quoted 158 lines

Signed-off-by Kai Kang <[email protected]>

---
  meta/recipes-multimedia/libav/libav.inc            |  2 -
  .../libav/libav/libav-fix-CVE-2014-9676.patch      | 98 ++++++++++++++++++++++
  meta/recipes-multimedia/libav/libav_9.16.bb        |  4 -
  meta/recipes-multimedia/libav/libav_9.18.bb        |  6 ++
  4 files changed, 104 insertions(+), 6 deletions(-)

meta/recipes-multimedia/libav/libav.inc +0 -2

index cac836f..6ef273b 100644
@@ -24,8 +24,6 @@ ARM_INSTRUCTION_SET = "arm"
 
  DEPENDS = "alsa-lib zlib libogg yasm-native"
 
-INC_PR = "r8"
-
  inherit autotools pkgconfig
 
  B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"

meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch new file +98 -0

new file mode 100644
index 0000000..1e31caa
@@ -0,0 +1,98 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2014-9676.
+
+https://security-tracker.debian.org/tracker/CVE-2014-9676
+https://git.libav.org/?p=libav.git;a=commit;h=b3f04657368a32a9903406395f865e230b1de348
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From b3f04657368a32a9903406395f865e230b1de348 Mon Sep 17 00:00:00 2001
+From: Luca Barbato <[email protected]>
+Date: Mon, 5 Jan 2015 10:40:41 +0100
+Subject: [PATCH] segment: Fix the failure paths
+
+A failure in segment_end() or segment_start() would lead to freeing
+a dangling pointer and in general further calls to seg_write_packet()
+or to seg_write_trailer() would have the same faulty behaviour.
+
+CC: [email protected]
+Reported-By: [email protected]
+---
+ libavformat/segment.c | 32 ++++++++++++++++++++------------
+ 1 file changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/libavformat/segment.c b/libavformat/segment.c
+index 52da6b9..bcfd1f9 100644
+--- a/libavformat/segment.c
++++ b/libavformat/segment.c
+@@ -184,6 +184,13 @@ static void close_null_ctx(AVIOContext *pb)
+     av_free(pb);
+ }
+
++static void seg_free_context(SegmentContext *seg)
++{
++    avio_closep(&seg->pb);
++    avformat_free_context(seg->avf);
++    seg->avf = NULL;
++}
++
+ static int seg_write_header(AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+@@ -265,12 +272,9 @@ static int seg_write_header(AVFormatContext *s)
+     }
+
+ fail:
+-    if (ret) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        if (seg->avf)
+-            avformat_free_context(seg->avf);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
++
+     return ret;
+ }
+
+@@ -282,6 +286,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     int64_t end_pts = seg->recording_time * seg->number;
+     int ret, can_split = 1;
+
++    if (!oc)
++        return AVERROR(EINVAL);
++
+     if (seg->has_video) {
+         can_split = st->codec->codec_type == AVMEDIA_TYPE_VIDEO &&
+                     pkt->flags & AV_PKT_FLAG_KEY;
+@@ -322,11 +329,8 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     ret = ff_write_chained(oc, pkt->stream_index, pkt, s);
+
+ fail:
+-    if (ret < 0) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        avformat_free_context(oc);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
+
+     return ret;
+ }
+@@ -335,7 +339,11 @@ static int seg_write_trailer(struct AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+     AVFormatContext *oc = seg->avf;
+-    int ret;
++    int ret = 0;
++
++    if (!oc)
++        goto fail;
++
+     if (!seg->write_header_trailer) {
+         if ((ret = segment_end(oc, 0)) < 0)
+             goto fail;
+--
+2.4.1.314.g9532ead
+

meta/recipes-multimedia/libav/libav_9.16.bb deleted +0 -4

deleted file mode 100644
index 79ff3f8..0000000
@@ -1,4 +0,0 @@
-require libav.inc
-
-SRC_URI[md5sum] = "7b44b75cec24b8e7545e5029e76917e0"
-SRC_URI[sha256sum] = "ca846473b0b8ed8e3404c52e5e92df6d35cb5fa487eec498525de3ffda4367a0"

meta/recipes-multimedia/libav/libav_9.18.bb new file +6 -1

new file mode 100644
index 0000000..210a649
@@ -0,0 +1,6 @@
+require libav.inc
+
+SRC_URI[md5sum] = "75e838068a75fb88e1b4ea0546bc16f0"
+SRC_URI[sha256sum] = "0875e835da683eef1a7bac75e1884634194149d7479d1538ba9fbe1614d066d7"
+
+SRC_URI += "file://libav-fix-CVE-2014-9676.patch"
--

1.9.1

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 8 lines

Regards,
Neil | Kai Kang

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Kang Kai

author

2015-05-29 01:37 UTC #11 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 25 lines · Martin Jansa

Quoted 15 lines · Kang Kai
Quoted 10 lines · Jussi Kukkonen
Quoted 2 lines · Kai Kang
Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.
I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?
I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.
The original thought is just in case someone may want libav 9. According to release log, series 11
is
Quoted 7 lines
"Libav 11 is API-, but not ABI-compatible with the previous major release."
So it is ok for us to use libav 11 as default. libav 9 recipe could be removed if no one opposes.
Ref:
https://libav.org/releases/libav-11.3.release
Does libav-11 show the same textrel issues? If it's fixed there I'm in favor of dropping libav-9.

Quoted 13 lines

from last world build:
gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/gstreamer1.0-libav/1.4.5-r0/packages-split/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/i586-oe-linux/gstreamer1.0-libav/1.4.5-r0/packages-split/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/libav/9.16-r0/packages-split/libavcodec/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavcodec/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavdevice/usr/lib/libavdevice.so.53.2.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavfilter/usr/lib/libavfilter.so.3.3.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavformat/usr/lib/libavformat.so.54.20.4' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavresample/usr/lib/libavresample.so.1.0.1' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavutil/usr/lib/libavutil.so.52.3.0' has relocations in .text [textrel]
libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libswscale/usr/lib/libswscale.so.2.1.1' has relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary '/tmp/work/armv5te-oe-linux-gnueabi/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary '/tmp/work/i586-oe-linux/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel]

No, the textrel issue is not fixed in version 11.3 either. It has an configure option '--enable-pic' but seems doesn't work. x86 has same warnings and it just skips the textrel check in the libav recipe.

--Kai

Quoted 169 lines

Quoted 159 lines

Signed-off-by Kai Kang <[email protected]>

---
   meta/recipes-multimedia/libav/libav.inc            |  2 -
   .../libav/libav/libav-fix-CVE-2014-9676.patch      | 98 ++++++++++++++++++++++
   meta/recipes-multimedia/libav/libav_9.16.bb        |  4 -
   meta/recipes-multimedia/libav/libav_9.18.bb        |  6 ++
   4 files changed, 104 insertions(+), 6 deletions(-)

meta/recipes-multimedia/libav/libav.inc +0 -2

index cac836f..6ef273b 100644
@@ -24,8 +24,6 @@ ARM_INSTRUCTION_SET = "arm"
 
   DEPENDS = "alsa-lib zlib libogg yasm-native"
 
-INC_PR = "r8"
-
   inherit autotools pkgconfig
 
   B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"

meta/recipes-multimedia/libav/libav/libav-fix-CVE-2014-9676.patch new file +98 -0

new file mode 100644
index 0000000..1e31caa
@@ -0,0 +1,98 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2014-9676.
+
+https://security-tracker.debian.org/tracker/CVE-2014-9676
+https://git.libav.org/?p=libav.git;a=commit;h=b3f04657368a32a9903406395f865e230b1de348
+
+Signed-off-by: Kai Kang <[email protected]>
+---
+From b3f04657368a32a9903406395f865e230b1de348 Mon Sep 17 00:00:00 2001
+From: Luca Barbato <[email protected]>
+Date: Mon, 5 Jan 2015 10:40:41 +0100
+Subject: [PATCH] segment: Fix the failure paths
+
+A failure in segment_end() or segment_start() would lead to freeing
+a dangling pointer and in general further calls to seg_write_packet()
+or to seg_write_trailer() would have the same faulty behaviour.
+
+CC: [email protected]
+Reported-By: [email protected]
+---
+ libavformat/segment.c | 32 ++++++++++++++++++++------------
+ 1 file changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/libavformat/segment.c b/libavformat/segment.c
+index 52da6b9..bcfd1f9 100644
+--- a/libavformat/segment.c
++++ b/libavformat/segment.c
+@@ -184,6 +184,13 @@ static void close_null_ctx(AVIOContext *pb)
+     av_free(pb);
+ }
+
++static void seg_free_context(SegmentContext *seg)
++{
++    avio_closep(&seg->pb);
++    avformat_free_context(seg->avf);
++    seg->avf = NULL;
++}
++
+ static int seg_write_header(AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+@@ -265,12 +272,9 @@ static int seg_write_header(AVFormatContext *s)
+     }
+
+ fail:
+-    if (ret) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        if (seg->avf)
+-            avformat_free_context(seg->avf);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
++
+     return ret;
+ }
+
+@@ -282,6 +286,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     int64_t end_pts = seg->recording_time * seg->number;
+     int ret, can_split = 1;
+
++    if (!oc)
++        return AVERROR(EINVAL);
++
+     if (seg->has_video) {
+         can_split = st->codec->codec_type == AVMEDIA_TYPE_VIDEO &&
+                     pkt->flags & AV_PKT_FLAG_KEY;
+@@ -322,11 +329,8 @@ static int seg_write_packet(AVFormatContext *s, AVPacket *pkt)
+     ret = ff_write_chained(oc, pkt->stream_index, pkt, s);
+
+ fail:
+-    if (ret < 0) {
+-        if (seg->list)
+-            avio_close(seg->pb);
+-        avformat_free_context(oc);
+-    }
++    if (ret < 0)
++        seg_free_context(seg);
+
+     return ret;
+ }
+@@ -335,7 +339,11 @@ static int seg_write_trailer(struct AVFormatContext *s)
+ {
+     SegmentContext *seg = s->priv_data;
+     AVFormatContext *oc = seg->avf;
+-    int ret;
++    int ret = 0;
++
++    if (!oc)
++        goto fail;
++
+     if (!seg->write_header_trailer) {
+         if ((ret = segment_end(oc, 0)) < 0)
+             goto fail;
+--
+2.4.1.314.g9532ead
+

meta/recipes-multimedia/libav/libav_9.16.bb deleted +0 -4

deleted file mode 100644
index 79ff3f8..0000000
@@ -1,4 +0,0 @@
-require libav.inc
-
-SRC_URI[md5sum] = "7b44b75cec24b8e7545e5029e76917e0"
-SRC_URI[sha256sum] = "ca846473b0b8ed8e3404c52e5e92df6d35cb5fa487eec498525de3ffda4367a0"

meta/recipes-multimedia/libav/libav_9.18.bb new file +6 -1

new file mode 100644
index 0000000..210a649
@@ -0,0 +1,6 @@
+require libav.inc
+
+SRC_URI[md5sum] = "75e838068a75fb88e1b4ea0546bc16f0"
+SRC_URI[sha256sum] = "0875e835da683eef1a7bac75e1884634194149d7479d1538ba9fbe1614d066d7"
+
+SRC_URI += "file://libav-fix-CVE-2014-9676.patch"
--

1.9.1

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 8 lines

Regards,
Neil | Kai Kang

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 2 lines

Regards,
Neil | Kai Kang

Paul Eggleton

2015-05-29 15:28 UTC #12 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 71 lines · On Friday 29 May 2015 09:36:28 Kang Kai wrote:

Quoted 61 lines · Martin Jansa
Quoted 17 lines · Kang Kai
Quoted 11 lines · Jussi Kukkonen
Quoted 2 lines · Kai Kang
Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and backport patch to fix CVE-2014-9676.
I'm sorry I didn't ask this in the original discussion but... Is there a good reason for keeping 9.x in oe-core if we're bringing in 11.x (instead of either dropping 9.x or moving it to meta-oe)?
I haven't found the API changes between 9 and 11 to be so large that they would warrant keeping two versions. Admittedly I'm not working with libav on daily basis so I might have missed things.
The original thought is just in case someone may want libav 9. According to release log, series 11
is
Quoted 8 lines
"Libav 11 is API-, but not ABI-compatible with the previous major release."
So it is ok for us to use libav 11 as default. libav 9 recipe could be removed if no one opposes.
Ref:
https://libav.org/releases/libav-11.3.release
Does libav-11 show the same textrel issues? If it's fixed there I'm in favor of dropping libav-9.
from last world build:
gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/gstreamer1.0-libav/1.4.5-r0/packages-s plit/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] gstreamer1.0-libav-1.4.5: ELF binary '/tmp/work/i586-oe-linux/gstreamer1.0-libav/1.4.5-r0/packages-split/gstre amer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/armv5e-oe-linux-gnueabi/libav/9.16-r0/packages-split/libavcode c/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavcodec/usr/lib/ libavcodec.so.54.35.0' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavdevice/usr/lib /libavdevice.so.53.2.0' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavfilter/usr/lib /libavfilter.so.3.3.0' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavformat/usr/lib /libavformat.so.54.20.4' has relocations in .text [textrel] libav-9.16:
ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavresample/usr/l ib/libavresample.so.1.0.1' has relocations in .text [textrel] libav-9.16:
ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavutil/usr/lib/l ibavutil.so.52.3.0' has relocations in .text [textrel] libav-9.16: ELF binary '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libswscale/usr/lib/ libswscale.so.2.1.1' has relocations in .text [textrel]
Quoted 8 lines
libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary '/tmp/work/armv5te-oe-linux-gnueabi/libpostproc/52.3.0+gitAUTOINC+811db3b 957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957:
ELF binary '/tmp/work/i586-oe-linux/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/pack ages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel]

Quoted 4 lines

No, the textrel issue is not fixed in version 11.3 either. It has an configure option '--enable-pic' but seems doesn't work.
x86 has same warnings and it just skips the textrel check in the libav recipe.

Just for background, the reason I disabled the textrel check for x86 in libav.inc was that I was able to determine based on quick research that upstream deliberately doesn't enable -fPIC for x86 (32-bit) because apparently it doesn't really work there. I honestly didn't check what the situation was on 32-bit ARM; I probably should have done that at the time.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Phil Blundell

2015-05-29 22:24 UTC #13 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 5 lines · Paul Eggleton

Just for background, the reason I disabled the textrel check for x86 in libav.inc was that I was able to determine based on quick research that upstream deliberately doesn't enable -fPIC for x86 (32-bit) because apparently it doesn't really work there. I honestly didn't check what the situation was on 32-bit ARM; I probably should have done that at the time.

PIC is particularly problematic on x86 because it ties up %ebx. This represents 25% of the available general purpose registers which can cause a measurable performance loss because of increased spilling, and in the particular case of libav there is a lot of hand-written assembly in the codecs which expects to be able to clobber that register. It certainly used to be the case that this code wouldn't compile at all under -fpic.

The performance thing does apply to ARM as well but to a slightly lesser extent. The second problem probably doesn't affect ARM at all. But, personally, I would disable the textrel check and build without -fpic on all platforms.

Bernhard Reutner-Fischer

2015-05-30 13:17 UTC #14 lore raw

Re: [PATCH 4/5] libav: upgrade to 9.18

Quoted 6 lines · Phil Blundell

Quoted 1 line · Paul Eggleton
Just for background, the reason I disabled the textrel check for x86
in
Quoted 1 line
libav.inc was that I was able to determine based on quick research
that
Quoted 1 line
upstream deliberately doesn't enable -fPIC for x86 (32-bit) because

Quoted 8 lines

apparently
Quoted 1 line
it doesn't really work there. I honestly didn't check what the
situation was
Quoted 1 line
on 32-bit ARM; I probably should have done that at the time.
PIC is particularly problematic on x86 because it ties up %ebx. This represents 25% of the available general purpose registers which can cause a measurable performance loss because of increased spilling, and

Note that the situation improved with gcc-5 for some cases though.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602
https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode

Cheers,

Kai Kang

author

2015-05-28 01:32 UTC #15 lore raw

PATCH 5/5 libav: add recipe for 11 release series

In reply to Kai Kang

Add recipe for libav 11 release series. According to release log, "Libav 11 is API-, but not ABI-compatible with the previous major release."

So make series 11 as default recipe.

Signed-off-by Kai Kang <[email protected]>

---
 meta/recipes-multimedia/libav/libav_11.3.bb | 4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 meta/recipes-multimedia/libav/libav_11.3.bb

meta/recipes-multimedia/libav/libav_11.3.bb new file +4 -0

new file mode 100644
index 0000000..49a6c8a
@@ -0,0 +1,4 @@
+require libav.inc
+
+SRC_URI[md5sum] = "16f896b12458fe7a0d5150e44e0639ec"
+SRC_URI[sha256sum] = "12ae6c051967765ae5faeddf94c4584129ac0b18edb884afffc5fcedcdb5e030"

Signature · 1 line

1.9.1