[OE-core] [PATCH resend V2 3/4] libarchive: CVE-2017-14503

[Jagadeesh Krishnanjanappa]

Reject LHA archive entries with negative size.

Affects libarchive = 3.3.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libarchive/libarchive/CVE-2017-14503.patch | 33 ++
 .../libarchive/libarchive_3.3.2.bb |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch

diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
new file mode 100644
index 000..3cb01db
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
@@ -0,0 +1,33 @@
+From 2c8c83b9731ff822fad6cc8c670ea5519c366a14 Mon Sep 17 00:00:00 2001
+From: Joerg Sonnenberger 
+Date: Thu, 19 Jul 2018 21:14:53 +0200
+Subject: [PATCH] Reject LHA archive entries with negative size.
+
+Upstream-Status: Backport 
[https://github.com/libarchive/libarchive/commit/2c8c83b9731ff822fad6cc8c670ea5519c366a14]
+CVE: CVE-2017-14503
+
+Signed-off-by: Jagadeesh Krishnanjanappa  
+---
+ libarchive/archive_read_support_format_lha.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_lha.c 
b/libarchive/archive_read_support_format_lha.c
+index b8ef4ae1..95c99bb1 100644
+--- a/libarchive/archive_read_support_format_lha.c
 b/libarchive/archive_read_support_format_lha.c
+@@ -701,6 +701,12 @@ archive_read_format_lha_read_header(struct archive_read 
*a,
+* Prepare variables used to read a file content.
+*/
+   lha->entry_bytes_remaining = lha->compsize;
++  if (lha->entry_bytes_remaining < 0) {
++  archive_set_error(>archive,
++  ARCHIVE_ERRNO_FILE_FORMAT,
++  "Invalid LHa entry size");
++  return (ARCHIVE_FATAL);
++  }
+   lha->entry_offset = 0;
+   lha->entry_crc_calculated = 0;
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb 
b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
index 5daca27..3269716 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
@@ -36,6 +36,7 @@ SRC_URI = 
"http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
file://CVE-2017-14166.patch \
file://CVE-2017-14502.patch \
file://non-recursive-extract-and-list.patch \
+   file://CVE-2017-14503.patch \
   "
 
 SRC_URI[md5sum] = "4583bd6b2ebf7e0e8963d90879eb1b27"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH resend V2 4/4] perl: CVE-2018-12015

[Jagadeesh Krishnanjanappa]

Remove existing files before overwriting them

Archive should extract only the latest same-named entry.
Extracted regular file should not be writtent into existing block
device (or any other one).

https://rt.cpan.org/Ticket/Display.html?id=125523

Affects perl <= 5.26.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../perl/perl/CVE-2018-12015.patch | 48 ++
 meta/recipes-devtools/perl/perl_5.24.4.bb  |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-12015.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
new file mode 100644
index 000..a33deaf
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
@@ -0,0 +1,48 @@
+From ae65651eab053fc6dc4590dbb863a268215c1fc5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 8 Jun 2018 11:45:40 +0100
+Subject: [PATCH] [PATCH] Remove existing files before overwriting them
+
+Archive should extract only the latest same-named entry.
+Extracted regular file should not be writtent into existing block
+device (or any other one).
+
+https://rt.cpan.org/Ticket/Display.html?id=125523
+
+CVE: CVE-2018-12015
+Upstream-Status: Backport 
[https://github.com/jib/archive-tar-new/commit/ae65651eab053fc6dc4590dbb863a268215c1fc5]
+
+Signed-off-by: Chris 'BinGOs' Williams 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/Archive/Tar.pm | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/cpan/Archive-Tar/lib/Archive/Tar.pm 
b/cpan/Archive-Tar/lib/Archive/Tar.pm
+index 6244369..a83975f 100644
+--- a/cpan/Archive-Tar/lib/Archive/Tar.pm
 b/cpan/Archive-Tar/lib/Archive/Tar.pm
+@@ -845,6 +845,20 @@ sub _extract_file {
+ return;
+ }
+ 
++### If a file system already contains a block device with the same name as
++### the being extracted regular file, we would write the file's content
++### to the block device. So remove the existing file (block device) now.
++### If an archive contains multiple same-named entries, the last one
++### should replace the previous ones. So remove the old file now.
++### If the old entry is a symlink to a file outside of the CWD, the new
++### entry would create a file there. This is CVE-2018-12015
++### .
++if (-l $full || -e _) {
++  if (!unlink $full) {
++  $self->_error( qq[Could not remove old file '$full': $!] );
++  return;
++  }
++}
+ if( length $entry->type && $entry->is_file ) {
+ my $fh = IO::File->new;
+ $fh->open( '>' . $full ) or (
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/perl/perl_5.24.4.bb 
b/meta/recipes-devtools/perl/perl_5.24.4.bb
index 4709d3e..1dce3bc 100644
--- a/meta/recipes-devtools/perl/perl_5.24.4.bb
+++ b/meta/recipes-devtools/perl/perl_5.24.4.bb
@@ -64,6 +64,7 @@ SRC_URI += " \
 file://perl-fix-conflict-between-skip_all-and-END.patch \
 file://perl-test-customized.patch \
 file://perl-5.26.1-guard_old_libcrypt_fix.patch \
+file://CVE-2018-12015.patch \
 "
 
 # Fix test case issues
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH resend V2 1/4] libsndfile1: CVE-2017-14245 CVE-2017-14246

[Jagadeesh Krishnanjanappa]

sfe_copy_data_fp: check value of "max" variable for being normal
and check elements of the data[] array for being finite.

Both checks use functions provided by the  header as declared
by the C99 standard.

Fixes #317
CVE-2017-14245
CVE-2017-14246

Affects libsndfile1 = 1.0.28

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libsndfile1/CVE-2017-14245-14246.patch | 121 +
 .../libsndfile/libsndfile1_1.0.28.bb   |   1 +
 2 files changed, 122 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
new file mode 100644
index 000..a17ec21
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
@@ -0,0 +1,121 @@
+From 2d54514a4f6437b67829717c05472d2e3300a258 Mon Sep 17 00:00:00 2001
+From: Fabian Greffrath 
+Date: Wed, 27 Sep 2017 14:46:17 +0200
+Subject: [PATCH] sfe_copy_data_fp: check value of "max" variable for being
+ normal
+
+and check elements of the data[] array for being finite.
+
+Both checks use functions provided by the  header as declared
+by the C99 standard.
+
+Fixes #317
+CVE: CVE-2017-14245
+CVE: CVE-2017-14246
+
+Upstream-Status: Backport 
[https://github.com/fabiangreffrath/libsndfile/commit/2d54514a4f6437b67829717c05472d2e3300a258]
+
+Signed-off-by: Fabian Greffrath 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ programs/common.c  | 20 
+ programs/common.h  |  2 +-
+ programs/sndfile-convert.c |  6 +-
+ 3 files changed, 22 insertions(+), 6 deletions(-)
+
+diff --git a/programs/common.c b/programs/common.c
+index a21e62c..a249a58 100644
+--- a/programs/common.c
 b/programs/common.c
+@@ -36,6 +36,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ 
+@@ -45,7 +46,7 @@
+ 
+ #define   MIN(x, y)   ((x) < (y) ? (x) : (y))
+ 
+-void
++int
+ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize)
+ { static double   data [BUFFER_LEN], max ;
+   int frames, readcount, k ;
+@@ -54,6 +55,8 @@ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int 
channels, int normalize
+   readcount = frames ;
+ 
+   sf_command (infile, SFC_CALC_SIGNAL_MAX, , sizeof (max)) ;
++  if (!isnormal (max)) /* neither zero, subnormal, infinite, nor NaN */
++  return 1 ;
+ 
+   if (!normalize && max < 1.0)
+   {   while (readcount > 0)
+@@ -67,12 +70,16 @@ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int 
channels, int normalize
+   while (readcount > 0)
+   {   readcount = sf_readf_double (infile, data, frames) ;
+   for (k = 0 ; k < readcount * channels ; k++)
+-  data [k] /= max ;
++  {   data [k] /= max ;
++
++  if (!isfinite (data [k])) /* infinite or NaN */
++  return 1;
++  }
+   sf_writef_double (outfile, data, readcount) ;
+   } ;
+   } ;
+ 
+-  return ;
++  return 0 ;
+ } /* sfe_copy_data_fp */
+ 
+ void
+@@ -252,7 +259,12 @@ sfe_apply_metadata_changes (const char * filenames [2], 
const METADATA_INFO * in
+ 
+   /* If the input file is not the same as the output file, copy 
the data. */
+   if ((infileminor == SF_FORMAT_DOUBLE) || (infileminor == 
SF_FORMAT_FLOAT))
+-  sfe_copy_data_fp (outfile, infile, sfinfo.channels, 
SF_FALSE) ;
++  {   if (sfe_copy_data_fp (outfile, infile, sfinfo.channels, 
SF_FALSE) != 0)
++  {   printf ("Error : Not able to decode input file 
'%s'\n", filenames [0]) ;
++  error_code = 1 ;
++  goto cleanup_exit ;
++  } ;
++  }
+   else
+   sfe_copy_data_int (outfile, infile, sfinfo.channels) ;
+   } ;
+diff --git a/programs/common.h b/programs/common.h
+index eda2d7d..986277e 100644
+--- a/programs/common.h
 b/programs/common.h
+@@ -62,7 +62,7 @@ typedef SF_BROADCAST_INFO_VAR (2048) SF_BROADCAST_INFO_2K ;
+ 
+ void sfe_apply_metadata_changes (const char * filenames [2], const 
METADATA_INFO * info) ;
+ 
+-void sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize) ;
++int sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize) ;
+ 
+ void sfe_copy_data_int (SNDFILE *outfile, SNDFILE *infile, int channels) ;
+ 
+diff --git a/programs/sndfile-convert.c b/programs/sndfile-convert.c
+index dff7f79..e6de593 100644
+--- a/programs/sndfile-convert.c
 b/programs/sndfile-convert.c
+@@ -335,7 +335,11 @@ 

[OE-core] [PATCH resend V2 2/4] libsndfile1: CVE-2017-14634

[Jagadeesh Krishnanjanappa]

double64_init: Check psf->sf.channels against upper bound

This prevents division by zero later in the code.

While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.

CVE-2017-14634

Closes: #318

Affects libsndfile1 = 1.0.28

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libsndfile/libsndfile1/CVE-2017-14634.patch| 42 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
new file mode 100644
index 000..39b4ec1
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
@@ -0,0 +1,42 @@
+From 85c877d5072866aadbe8ed0c3e0590fbb5e16788 Mon Sep 17 00:00:00 2001
+From: Fabian Greffrath 
+Date: Thu, 28 Sep 2017 12:15:04 +0200
+Subject: [PATCH] double64_init: Check psf->sf.channels against upper bound
+
+This prevents division by zero later in the code.
+
+While the trivial case to catch this (i.e. sf.channels < 1) has already
+been covered, a crafted file may report a number of channels that is
+so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
+miscalculated to zero (if this makes sense) in the determination of the
+blockwidth. Since we only support a limited number of channels anyway,
+make sure to check here as well.
+
+CVE: CVE-2017-14634
+
+Closes: https://github.com/erikd/libsndfile/issues/318
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/85c877d5072866aadbe8ed0c3e0590fbb5e16788]
+
+Signed-off-by: Erik de Castro Lopo 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/double64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/double64.c b/src/double64.c
+index b318ea8..78dfef7 100644
+--- a/src/double64.c
 b/src/double64.c
+@@ -91,7 +91,7 @@ int
+ double64_init (SF_PRIVATE *psf)
+ { static int double64_caps ;
+ 
+-  if (psf->sf.channels < 1)
++  if (psf->sf.channels < 1 || psf->sf.channels > SF_MAX_CHANNELS)
+   {   psf_log_printf (psf, "double64_init : internal error : channels 
= %d\n", psf->sf.channels) ;
+   return SFE_INTERNAL ;
+   } ;
+-- 
+2.13.3
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index c6f2a46..ed43b74 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2017-8362.patch \
file://CVE-2017-8363.patch \
file://CVE-2017-14245-14246.patch \
+   file://CVE-2017-14634.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] openssl: remove dependency on relative_symlinks class

[Andre McCurdy]

Although the relative_symlinks class converts any absolute symlinks
in ${D} into relative symlinks automatically, it's a little clearer
to create relative symlinks directly where possible.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-connectivity/openssl/openssl_1.0.2p.bb | 11 +++
 meta/recipes-connectivity/openssl/openssl_1.1.0i.bb | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb
index 1abf894..dbcb000 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb
@@ -58,7 +58,7 @@ SRC_URI[sha256sum] = 
"50a98e07b1a89eb8f6a99477f262df71c6fa7bef77df4dc83025a2845c
 
 UPSTREAM_CHECK_REGEX = "openssl-(?P1\.0.+)\.tar"
 
-inherit pkgconfig siteinfo multilib_header ptest relative_symlinks manpages
+inherit pkgconfig siteinfo multilib_header ptest manpages
 
 PACKAGECONFIG ?= "cryptodev-linux"
 PACKAGECONFIG_class-native = ""
@@ -242,9 +242,12 @@ do_install () {
   ${D}${libdir}/ssl/private \
   ${D}${libdir}/ssl/openssl.cnf \
   ${D}${sysconfdir}/ssl/
-   ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl/certs
-   ln -sf ${sysconfdir}/ssl/private ${D}${libdir}/ssl/private
-   ln -sf ${sysconfdir}/ssl/openssl.cnf ${D}${libdir}/ssl/openssl.cnf
+
+   # Although absolute symlinks would be OK for the target, they become
+   # invalid if native or nativesdk are relocated from sstate.
+   ln -sf ${@oe.path.relative('${libdir}/ssl', '${sysconfdir}/ssl/certs')} 
${D}${libdir}/ssl/certs
+   ln -sf ${@oe.path.relative('${libdir}/ssl', 
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl/private
+   ln -sf ${@oe.path.relative('${libdir}/ssl', 
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl/openssl.cnf
 
# Rename man pages to prefix openssl10-*
for f in `find ${D}${mandir} -type f`; do
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
index d2f2624..a03f6ff 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
@@ -24,7 +24,7 @@ SRC_URI_append_class-nativesdk = " \
 SRC_URI[md5sum] = "9495126aafd2659d357ea66a969c3fe1"
 SRC_URI[sha256sum] = 
"ebbfc844a8c8cc0ea5dc10b86c9ce97f401837f3fa08c17b2cdadc118253cf99"
 
-inherit lib_package multilib_header ptest relative_symlinks
+inherit lib_package multilib_header ptest
 
 #| ./libcrypto.so: undefined reference to `getcontext'
 #| ./libcrypto.so: undefined reference to `setcontext'
@@ -114,9 +114,12 @@ do_install () {
   ${D}${libdir}/ssl-1.1/private \
   ${D}${libdir}/ssl-1.1/openssl.cnf \
   ${D}${sysconfdir}/ssl/
-   ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl-1.1/certs
-   ln -sf ${sysconfdir}/ssl/private ${D}${libdir}/ssl-1.1/private
-   ln -sf ${sysconfdir}/ssl/openssl.cnf ${D}${libdir}/ssl-1.1/openssl.cnf
+
+   # Although absolute symlinks would be OK for the target, they become
+   # invalid if native or nativesdk are relocated from sstate.
+   ln -sf ${@oe.path.relative('${libdir}/ssl-1.1', 
'${sysconfdir}/ssl/certs')} ${D}${libdir}/ssl-1.1/certs
+   ln -sf ${@oe.path.relative('${libdir}/ssl-1.1', 
'${sysconfdir}/ssl/private')} ${D}${libdir}/ssl-1.1/private
+   ln -sf ${@oe.path.relative('${libdir}/ssl-1.1', 
'${sysconfdir}/ssl/openssl.cnf')} ${D}${libdir}/ssl-1.1/openssl.cnf
 }
 
 do_install_append_class-native () {
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] python3: enable profile optimized builds

[Andre McCurdy]

On Thu, Aug 16, 2018 at 9:48 PM, Anuj Mittal  wrote:
> On 08/17/2018 03:31 AM, Andre McCurdy wrote:
>> On Wed, Aug 15, 2018 at 11:26 PM, Anuj Mittal  wrote:
>>> Enable profile guided optimization (pgo) for python3. Enabling pgo in
>>> python is generally as simple as invoking the target profile-opt which:
>>>
>>> - builds python binaries with profile instrumentation enabled,
>>> - runs a specific profile task using that python to get the profile
>>> data and,
>>> - feeds the compiler with this profile data and rebuilds python.
>>>
>>> This change invokes qemu-user for the second step of running a profile
>>> task using target python. Depending on how long profile task takes to
>>> run, this might add a significant time to compilation (which would be
>>> true for native builds too). The default profile task can be changed by
>>> the users depending on what makes sense for their use case (or can be
>>> left empty). In case qemu-user isn't supported, profile task won't be run.
>>
>> Is it important to re-create the profile data during every build or
>> would we get most of the same benefits from using reference data which
>> is generated offline?
>
> We should get the same benefit using the data generated offline as long
> as the source code/configure options/flags are same I believe. I have
> only tried with data generate offline using the same build configuration
> though.

As an additional data point, python do_compile now takes approx 18
minutes on my laptop. A single qemu-i386 thread loading one CPU core
at 100%, with nothing else being scheduled in parallel for most of
that time.

If we can get most of the benefits of pgo with a pre-generated data
file then that might still be something to explore.

> It would however need tweaking of the Makefiles to pass
> -fprofile-dir= while using the profile data among other things.
> Please see this if you'd like an example that works:
>
> https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/commit/?h=anujm/9338=e57654cb51b121e9dfa76e66432c4d37fd339d42
>
>> How big is the data file? Is it binary or text?
>
> gcc -fprofile-generate generates .gcda files which are used only for
> profile use and can be deleted later and aren't installed. For more
> information:
>
> https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html
>
>> Is the data expected to be target architecture specific?>
>> If reference data were used, what are the consequences of the data not
>> corresponding exactly to the current build configuration? A build
>> failure? Or just a decrease in the effectiveness of the optimisation?
>
> From gcc man page:
>
> "By default, GCC emits an error message if the feedback profiles do not
> match the source code. This error can be turned into a warning by using
> -Wcoverage-mismatch. Note this may result in poorly optimized code."
>
>>
>> Does the profiling instrumentation measure execution timing? Or only
>> the frequency / order in which functions are called? ie is there any
>> concern that data generated from running under qemu may not be optimal
>> for running on the target?
>
> It tries to identify code hot spots, how many times each branch and call
> is executed and how many times it is taken or returns etc. so I don't
> think it should matter. I did try on target hardware and using qemu as
> well and at least performance wise, I didn't see any difference. I
> didn't perform any exhaustive analysis though.
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Andre McCurdy]

On Wed, Aug 22, 2018 at 2:56 PM, Ryan Harkin  wrote:
> On Wed, 22 Aug 2018, 21:42 Andre McCurdy,  wrote:
>> On Wed, Aug 22, 2018 at 1:10 PM, Ryan Harkin 
>> wrote:
>> > On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:
>> >>
>> >> Your 1st parameter is wrong, compare again with the example I gave you
>> >> (don't include "brcm/" path in 1st param, because you want the symlink
>> >> to
>> >> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
>> >> after cd).
>> >
>> > That doesn't work either. I tried it with the same result, but didn't
>> > send a
>> > log of it. That works for you?
>>
>> Martin's example is correct so maybe check your tests again for typos.
>> It it still doesn't work then please do send a log.
>>
>> The link will point to whatever you define via the first parameter, so
>> if you changed the first parameter it shouldn't be possible to get
>> "the same result".
>>
>>   $ mkdir foo
>>   $ ln -sf test_target foo/test1
>>   $ ln -sf brcm/test_target foo/test2
>>   $ ls -l foo
>>
>>   lrwxrwxrwx 1 andre andre 11 Aug 22 13:35 test1 -> test_target
>>   lrwxrwxrwx 1 andre andre 16 Aug 22 13:35 test2 -> brcm/test_target
>
> Yes, that's essentially the same as what I'm getting.
>
> Now try "cat foo/test1" and what happens?
>
> There is no file called test_target in the foo directory. And neither is
> there a file called brcm/test_target in the foo directory.

Correct. The above was just an example to show that you can * create
symlinks * in the foo directory without cd'ing into the foo directory
first.

If you'd like the symlinks in the example to point to valid targets
then you need to create the targets too, e.g.

  $ mkdir -p foo/brcm
  $ echo hello > foo/test_target
  $ echo hello2 > foo/brcm/test_target

But note that the process of creating a symlink is always the same,
regardless of whether the symlink points to a valid target or not (so
you can run these extra commands to create the targets before or after
you create the symlinks).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Face some linker errors recently

[Andreas Müller]

On Thu, Aug 23, 2018 at 12:17 AM, Andreas Müller
 wrote:
> Hi,
>
> to test my patches, I moved my layers from sumo to recent master and
> see similar linker (=gold) errors in different recipes. Up to now
> there are:
>
And

meta-qt5-extra/krita:
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/../../libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/8.2.0/ld:
warning: discarding version information for __cxa_finalize@GLIBC_2.4,
defined in unused shared library <...>/recipe-sysroot/lib/libc.so.6
(linked with --as-needed)
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/../../libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/8.2.0/ld:
error: treating warnings as errors
collect2: error: ld returned 1 exit status

won't post further - promised :)

Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] libxml-parser-perl: fix "...contains bad RPATH"

[Richard Purdie]

On Wed, 2018-08-22 at 16:56 +0100, Richard Purdie wrote:
> Sorry, this fails to build the nativesdk version:
> 
> https://autobuilder.yocto.io/builders/nightly-x86/builds/1261/steps/B
> uilding%20Toolchain%20Images/logs/stdio
> 
> I suspect you need to strip the RPATH in the nativesdk case...

http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next=3fc37317a78b19ce4eea10dad73a17186c68ff58

added to your patch 'fixes' it...

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Face some linker errors recently

[Andreas Müller]

Hi,

to test my patches, I moved my layers from sumo to recent master and
see similar linker (=gold) errors in different recipes. Up to now
there are:

meta-qt5-extra/kwallet:
FAILED: bin/libkwalletbackend5.so.5.49.0
: && 
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-g++
-fPIC -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard
-mcpu=cortex-a7  --sysroot=<...>/recipe-sysroot  -O2 -pipe -g
-feliminate-unused-debug-types
-fdebug-prefix-map=/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-angstrom-linux-gnueabi/kwallet/5.49.0-r0=/usr/src/debug/kwallet/5.49.0-r0
-fdebug-prefix-map=<...>/recipe-sysroot=
-fdebug-prefix-map=<...>/recipe-sysroot-native=
-fvisibility-inlines-hidden  -march=armv7ve -mthumb -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7  --sysroot=<...>/recipe-sysroot
-std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra
-Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
-Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual
-Werror=return-type -Wvla -Wdate-time -fdiagnostics-color=always
-pedantic -Wsuggest-override -Wlogical-op
-Wzero-as-null-pointer-constant  -Wl,--no-undefined
-Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -shared
-Wl,-soname,libkwalletbackend5.so.5 -o
bin/libkwalletbackend5.so.5.49.0
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/blockcipher.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/blowfish.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/cbc.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/sha1.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletentry.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletbackend.cc.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/backendpersisthandler.cpp.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletbackend_debug.cpp.o
src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletbackend5_autogen/mocs_compilation.cpp.o
 <...>/recipe-sysroot/usr/lib/libKF5WidgetsAddons.so.5.49.0
<...>/recipe-sysroot/usr/lib/libKF5Notifications.so.5.49.0
<...>/recipe-sysroot/usr/lib/libKF5I18n.so.5.49.0 -lgcrypt
<...>/recipe-sysroot/usr/lib//libgpgmepp.so
<...>/recipe-sysroot/usr/lib/libKF5CoreAddons.so.5.49.0
<...>/recipe-sysroot/usr/lib/libQt5DBus.so.5.11.1
<...>/recipe-sysroot/usr/lib/libQt5Widgets.so.5.11.1
<...>/recipe-sysroot/usr/lib/libQt5Gui.so.5.11.1
<...>/recipe-sysroot/usr/lib/libQt5Core.so.5.11.1 -lpthread -lgpgme
-lassuan && :
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/../../libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/8.2.0/ld:
warning: discarding version information for
__pthread_key_create@GLIBC_2.4, defined in unused shared library
<...>/recipe-sysroot/usr/lib/libpthread.so (linked with --as-needed)
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/../../libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/8.2.0/ld:
error: treating warnings as errors
collect2: error: ld returned 1 exit status


meta-qt5-extra/kio-extras:
FAILED: thumbnail/svgthumbnail.so
: && 
<...>/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-g++
-fPIC -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard
-mcpu=cortex-a7  --sysroot=<...>/recipe-sysroot  -O2 -pipe -g
-feliminate-unused-debug-types
-fdebug-prefix-map=/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-neon-vfpv4-angstrom-linux-gnueabi/kio-extras/18.04.2-r0=/usr/src/debug/kio-extras/18.04.2-r0
-fdebug-prefix-map=<...>/recipe-sysroot=
-fdebug-prefix-map=<...>/recipe-sysroot-native=
-fvisibility-inlines-hidden  -march=armv7ve -mthumb -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7  --sysroot=<...>/recipe-sysroot
-std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra
-Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
-Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual
-Werror=return-type -Wvla -Wdate-time -fdiagnostics-color=always
-Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -shared  -o
thumbnail/svgthumbnail.so
thumbnail/CMakeFiles/svgthumbnail.dir/svgcreator.cpp.o
thumbnail/CMakeFiles/svgthumbnail.dir/svgthumbnail_autogen/mocs_compilation.cpp.o
 <...>/recipe-sysroot/usr/lib/libKF5KIOWidgets.so.5.49.0
<...>/recipe-sysroot/usr/lib/libKF5KIOCore.so.5.49.0
<...>/recipe-sysroot/usr/lib/libKF5Service.so.5.49.0
<...>/recipe-sysroot/usr/lib/libQt5Network.so.5.11.1
<...>/recipe-sysroot/usr/lib/libQt5Concurrent.so.5.11.1
<...>/recipe-sysroot/usr/lib/libKF5JobWidgets.so.5.49.0
<...>/recipe-sysroot/usr/lib/libKF5Completion.so.5.49.0
<...>/recipe-sysroot/usr/lib/libQt5Svg.so.5.11.1
<...>/recipe-sysroot/usr/lib/libKF5WidgetsAddons.so.5.49.0
<...>/recipe-sysroot/usr/lib/libQt5Widgets.so.5.11.1

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

On Wed, 22 Aug 2018, 21:42 Andre McCurdy,  wrote:

> On Wed, Aug 22, 2018 at 1:10 PM, Ryan Harkin 
> wrote:
> > On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:
> >>
> >> Your 1st parameter is wrong, compare again with the example I gave you
> >> (don't include "brcm/" path in 1st param, because you want the symlink
> to
> >> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
> >> after cd).
> >
> > That doesn't work either. I tried it with the same result, but didn't
> send a
> > log of it. That works for you?
>
> Martin's example is correct so maybe check your tests again for typos.
> It it still doesn't work then please do send a log.
>
> The link will point to whatever you define via the first parameter, so
> if you changed the first parameter it shouldn't be possible to get
> "the same result".
>
>   $ mkdir foo
>   $ ln -sf test_target foo/test1
>   $ ln -sf brcm/test_target foo/test2
>   $ ls -l foo
>
>   lrwxrwxrwx 1 andre andre 11 Aug 22 13:35 test1 -> test_target
>   lrwxrwxrwx 1 andre andre 16 Aug 22 13:35 test2 -> brcm/test_target
>

Yes, that's essentially the same as what I'm getting.

Now try "cat foo/test1" and what happens?

There is no file called test_target in the foo directory. And neither is
there a file called brcm/test_target in the foo directory.

>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

On Wed, 22 Aug 2018, 21:36 Khem Raj,  wrote:

> I wonder how it work with meta-raspverrypi now that it has its own
> packing for firmware
>

Sorry Them, I don't understand your question.


On Wed, Aug 22, 2018 at 1:10 PM Ryan Harkin  wrote:
> >
> >
> >
> > On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:
> >>
> >> Your 1st parameter is wrong, compare again with the example I gave you
> (don't include "brcm/" path in 1st param, because you want the symlink to
> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
> after cd).
> >
> >
> > That doesn't work either. I tried it with the same result, but didn't
> send a log of it. That works for you?
> >
> >
> >> On Wed, Aug 22, 2018 at 7:11 PM Ryan Harkin 
> wrote:
> >>>
> >>> This is curious!
> >>>
> >>> On 22 August 2018 at 17:56, Martin Jansa 
> wrote:
> 
>  cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt
> 
>  is the same as
> 
>  ln -sf brcmfmac43430-sdio.AP6212.txt
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
> >>>
> >>>
> >>> On my system, this is what happens when I'm in the root of the
> linux-firmware repo:
> >>>
> >>> $ ls -al brcm/*.txt
> >>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08
> brcm/brcmfmac43430-sdio.AP6212.txt
> >>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48
> brcm/brcmfmac43430-sdio.MUR1DX.txt
> >>>
> >>> $ ln -sf brcm/brcmfmac43430-sdio.AP6212.txt brcm/brcmfmac43430-sdio.txt
> >>>
> >>> $ ls -al brcm/*.txt
> >>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08
> brcm/brcmfmac43430-sdio.AP6212.txt
> >>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48
> brcm/brcmfmac43430-sdio.MUR1DX.txt
> >>> lrwxrwxrwx 1 ryan ryan  34 Aug 22 18:08 brcm/brcmfmac43430-sdio.txt ->
> brcm/brcmfmac43430-sdio.AP6212.txt
> >>>
> >>> And the file is not valid.
> >>>
> >>> $ cat brcm/brcmfmac43430-sdio.txt
> >>> cat: brcm/brcmfmac43430-sdio.txt: No such file or directory
> >>>
> >>> So perhaps I'm doing something wrong. I tried your suggestion
> originally and it didn't work for me. Maybe I made a typo or something?
> >>>
> >>>
> 
>  On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin 
> wrote:
> >
> >
> >
> > On 22 August 2018 at 17:41, Martin Jansa 
> wrote:
> >>
> >> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to
> be needed, just include the path in 2nd ln parameter.
> >
> >
> > I don't think that works, or at least, it doesn't work for me, so I
> may be doing something wrong. I'm also copying the example used in the
> do_install() a few lines up as I figured that would be the preferred style
> for this recipe.
> >
> >>
> >> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
> wrote:
> >>>
> >>> The Linux kernel currently expects a single NVRAM file for BCM43430
> >>> named brcmfmac43430-sdio.txt.
> >>>
> >>> Allow the machine to specify an override to link its module
> specific
> >>> NVRAM to the filename expected by the kernel.
> >>>
> >>> Signed-off-by: Ryan Harkin 
> >>> ---
> >>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
> 
> >>>  1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/meta/recipes-kernel/linux-firmware/
> linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/
> linux-firmware_git.bb
> >>> index 8c54f28..b647abc 100644
> >>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> >>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> >>> @@ -226,6 +226,18 @@ do_install() {
> >>> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
> ti-connectivity/* . )
> >>>  }
> >>>
> >>> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will
> create a
> >>> +# softlink for the module specific NVRAM file to the filename
> expected
> >>> +# by the Linux kernel
> >>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> >>> +do_install_append_bcm43430-nvram-mur1dx() {
> >>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
> >>> +}
> >>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> >>> +do_install_append_bcm43430-nvram-ap6212() {
> >>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
> >>> +}
> >>> +
> >>>
> >>>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
> >>>   ${PN}-mt7601u-license ${PN}-mt7601u \
> >>> --
> >>> 2.7.4
> >>>
> >
> >>>
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Andre McCurdy]

On Wed, Aug 22, 2018 at 1:10 PM, Ryan Harkin  wrote:
> On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:
>>
>> Your 1st parameter is wrong, compare again with the example I gave you
>> (don't include "brcm/" path in 1st param, because you want the symlink to
>> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
>> after cd).
>
> That doesn't work either. I tried it with the same result, but didn't send a
> log of it. That works for you?

Martin's example is correct so maybe check your tests again for typos.
It it still doesn't work then please do send a log.

The link will point to whatever you define via the first parameter, so
if you changed the first parameter it shouldn't be possible to get
"the same result".

  $ mkdir foo
  $ ln -sf test_target foo/test1
  $ ln -sf brcm/test_target foo/test2
  $ ls -l foo

  lrwxrwxrwx 1 andre andre 11 Aug 22 13:35 test1 -> test_target
  lrwxrwxrwx 1 andre andre 16 Aug 22 13:35 test2 -> brcm/test_target
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Khem Raj]

I wonder how it work with meta-raspverrypi now that it has its own
packing for firmware
On Wed, Aug 22, 2018 at 1:10 PM Ryan Harkin  wrote:
>
>
>
> On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:
>>
>> Your 1st parameter is wrong, compare again with the example I gave you 
>> (don't include "brcm/" path in 1st param, because you want the symlink to 
>> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version 
>> after cd).
>
>
> That doesn't work either. I tried it with the same result, but didn't send a 
> log of it. That works for you?
>
>
>> On Wed, Aug 22, 2018 at 7:11 PM Ryan Harkin  wrote:
>>>
>>> This is curious!
>>>
>>> On 22 August 2018 at 17:56, Martin Jansa  wrote:

 cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf 
 brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt

 is the same as

 ln -sf brcmfmac43430-sdio.AP6212.txt 
 ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
>>>
>>>
>>> On my system, this is what happens when I'm in the root of the 
>>> linux-firmware repo:
>>>
>>> $ ls -al brcm/*.txt
>>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
>>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
>>>
>>> $ ln -sf brcm/brcmfmac43430-sdio.AP6212.txt brcm/brcmfmac43430-sdio.txt
>>>
>>> $ ls -al brcm/*.txt
>>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
>>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
>>> lrwxrwxrwx 1 ryan ryan  34 Aug 22 18:08 brcm/brcmfmac43430-sdio.txt -> 
>>> brcm/brcmfmac43430-sdio.AP6212.txt
>>>
>>> And the file is not valid.
>>>
>>> $ cat brcm/brcmfmac43430-sdio.txt
>>> cat: brcm/brcmfmac43430-sdio.txt: No such file or directory
>>>
>>> So perhaps I'm doing something wrong. I tried your suggestion originally 
>>> and it didn't work for me. Maybe I made a typo or something?
>>>
>>>

 On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin  wrote:
>
>
>
> On 22 August 2018 at 17:41, Martin Jansa  wrote:
>>
>> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be 
>> needed, just include the path in 2nd ln parameter.
>
>
> I don't think that works, or at least, it doesn't work for me, so I may 
> be doing something wrong. I'm also copying the example used in the 
> do_install() a few lines up as I figured that would be the preferred 
> style for this recipe.
>
>>
>> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin  
>> wrote:
>>>
>>> The Linux kernel currently expects a single NVRAM file for BCM43430
>>> named brcmfmac43430-sdio.txt.
>>>
>>> Allow the machine to specify an override to link its module specific
>>> NVRAM to the filename expected by the kernel.
>>>
>>> Signed-off-by: Ryan Harkin 
>>> ---
>>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12 
>>> 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
>>> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> index 8c54f28..b647abc 100644
>>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> @@ -226,6 +226,18 @@ do_install() {
>>> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf 
>>> ti-connectivity/* . )
>>>  }
>>>
>>> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
>>> +# softlink for the module specific NVRAM file to the filename expected
>>> +# by the Linux kernel
>>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = " 
>>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>>> +do_install_append_bcm43430-nvram-mur1dx() {
>>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf 
>>> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
>>> +}
>>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 = 
>>> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>>> +do_install_append_bcm43430-nvram-ap6212() {
>>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf 
>>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
>>> +}
>>> +
>>>
>>>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>>>   ${PN}-mt7601u-license ${PN}-mt7601u \
>>> --
>>> 2.7.4
>>>
>
>>>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

On Wed, 22 Aug 2018, 20:02 Martin Jansa,  wrote:

> Your 1st parameter is wrong, compare again with the example I gave you
> (don't include "brcm/" path in 1st param, because you want the symlink to
> point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
> after cd).
>

That doesn't work either. I tried it with the same result, but didn't send
a log of it. That works for you?


On Wed, Aug 22, 2018 at 7:11 PM Ryan Harkin  wrote:
>
>> This is curious!
>>
>> On 22 August 2018 at 17:56, Martin Jansa  wrote:
>>
>>> cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt
>>>
>>> is the same as
>>>
>>> ln -sf brcmfmac43430-sdio.AP6212.txt ${D}${nonarch_base_libdir}/fir
>>> mware/brcm/brcmfmac43430-sdio.txt
>>>
>>
>> On my system, this is what happens when I'm in the root of the
>> linux-firmware repo:
>>
>> $ ls -al brcm/*.txt
>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
>>
>> $ ln -sf brcm/brcmfmac43430-sdio.AP6212.txt brcm/brcmfmac43430-sdio.txt
>>
>> $ ls -al brcm/*.txt
>> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
>> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
>> lrwxrwxrwx 1 ryan ryan  34 Aug 22 18:08 brcm/brcmfmac43430-sdio.txt ->
>> brcm/brcmfmac43430-sdio.AP6212.txt
>>
>> And the file is not valid.
>>
>> $ cat brcm/brcmfmac43430-sdio.txt
>> cat: brcm/brcmfmac43430-sdio.txt: No such file or directory
>>
>> So perhaps I'm doing something wrong. I tried your suggestion originally
>> and it didn't work for me. Maybe I made a typo or something?
>>
>>
>>
>>> On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin 
>>> wrote:
>>>


 On 22 August 2018 at 17:41, Martin Jansa 
 wrote:

> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
> needed, just include the path in 2nd ln parameter.
>

 I don't think that works, or at least, it doesn't work for me, so I may
 be doing something wrong. I'm also copying the example used in the
 do_install() a few lines up as I figured that would be the preferred style
 for this recipe.


> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
> wrote:
>
>> The Linux kernel currently expects a single NVRAM file for BCM43430
>> named brcmfmac43430-sdio.txt.
>>
>> Allow the machine to specify an override to link its module specific
>> NVRAM to the filename expected by the kernel.
>>
>> Signed-off-by: Ryan Harkin 
>> ---
>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
>> 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> index 8c54f28..b647abc 100644
>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> @@ -226,6 +226,18 @@ do_install() {
>> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
>> ti-connectivity/* . )
>>  }
>>
>> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will
>> create a
>> +# softlink for the module specific NVRAM file to the filename
>> expected
>> +# by the Linux kernel
>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>> +do_install_append_bcm43430-nvram-mur1dx() {
>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
>> +}
>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
>> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>> +do_install_append_bcm43430-nvram-ap6212() {
>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
>> +}
>> +
>>
>>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>>   ${PN}-mt7601u-license ${PN}-mt7601u \
>> --
>> 2.7.4
>>
>>

>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Martin Jansa]

Your 1st parameter is wrong, compare again with the example I gave you
(don't include "brcm/" path in 1st param, because you want the symlink to
point to just brcmfmac43430-sdio.AP6212.txt like you did in the version
after cd).

On Wed, Aug 22, 2018 at 7:11 PM Ryan Harkin  wrote:

> This is curious!
>
> On 22 August 2018 at 17:56, Martin Jansa  wrote:
>
>> cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt
>>
>> is the same as
>>
>> ln -sf brcmfmac43430-sdio.AP6212.txt ${D}${nonarch_base_libdir}/fir
>> mware/brcm/brcmfmac43430-sdio.txt
>>
>
> On my system, this is what happens when I'm in the root of the
> linux-firmware repo:
>
> $ ls -al brcm/*.txt
> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
>
> $ ln -sf brcm/brcmfmac43430-sdio.AP6212.txt brcm/brcmfmac43430-sdio.txt
>
> $ ls -al brcm/*.txt
> -rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
> -rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
> lrwxrwxrwx 1 ryan ryan  34 Aug 22 18:08 brcm/brcmfmac43430-sdio.txt ->
> brcm/brcmfmac43430-sdio.AP6212.txt
>
> And the file is not valid.
>
> $ cat brcm/brcmfmac43430-sdio.txt
> cat: brcm/brcmfmac43430-sdio.txt: No such file or directory
>
> So perhaps I'm doing something wrong. I tried your suggestion originally
> and it didn't work for me. Maybe I made a typo or something?
>
>
>
>> On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin 
>> wrote:
>>
>>>
>>>
>>> On 22 August 2018 at 17:41, Martin Jansa  wrote:
>>>
 The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
 needed, just include the path in 2nd ln parameter.

>>>
>>> I don't think that works, or at least, it doesn't work for me, so I may
>>> be doing something wrong. I'm also copying the example used in the
>>> do_install() a few lines up as I figured that would be the preferred style
>>> for this recipe.
>>>
>>>
 On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
 wrote:

> The Linux kernel currently expects a single NVRAM file for BCM43430
> named brcmfmac43430-sdio.txt.
>
> Allow the machine to specify an override to link its module specific
> NVRAM to the filename expected by the kernel.
>
> Signed-off-by: Ryan Harkin 
> ---
>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
> 
>  1 file changed, 12 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index 8c54f28..b647abc 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -226,6 +226,18 @@ do_install() {
> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
> ti-connectivity/* . )
>  }
>
> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create
> a
> +# softlink for the module specific NVRAM file to the filename expected
> +# by the Linux kernel
> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> +do_install_append_bcm43430-nvram-mur1dx() {
> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
> +}
> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> +do_install_append_bcm43430-nvram-ap6212() {
> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
> +}
> +
>
>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-mt7601u-license ${PN}-mt7601u \
> --
> 2.7.4
>
>
>>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

This is curious!

On 22 August 2018 at 17:56, Martin Jansa  wrote:

> cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt
>
> is the same as
>
> ln -sf brcmfmac43430-sdio.AP6212.txt ${D}${nonarch_base_libdir}/fir
> mware/brcm/brcmfmac43430-sdio.txt
>

On my system, this is what happens when I'm in the root of the
linux-firmware repo:

$ ls -al brcm/*.txt
-rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
-rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt

$ ln -sf brcm/brcmfmac43430-sdio.AP6212.txt brcm/brcmfmac43430-sdio.txt

$ ls -al brcm/*.txt
-rw-rw-r-- 1 ryan ryan 875 Aug 22 18:08 brcm/brcmfmac43430-sdio.AP6212.txt
-rw-rw-r-- 1 ryan ryan 831 Aug 21 14:48 brcm/brcmfmac43430-sdio.MUR1DX.txt
lrwxrwxrwx 1 ryan ryan  34 Aug 22 18:08 brcm/brcmfmac43430-sdio.txt ->
brcm/brcmfmac43430-sdio.AP6212.txt

And the file is not valid.

$ cat brcm/brcmfmac43430-sdio.txt
cat: brcm/brcmfmac43430-sdio.txt: No such file or directory

So perhaps I'm doing something wrong. I tried your suggestion originally
and it didn't work for me. Maybe I made a typo or something?



> On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin 
> wrote:
>
>>
>>
>> On 22 August 2018 at 17:41, Martin Jansa  wrote:
>>
>>> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
>>> needed, just include the path in 2nd ln parameter.
>>>
>>
>> I don't think that works, or at least, it doesn't work for me, so I may
>> be doing something wrong. I'm also copying the example used in the
>> do_install() a few lines up as I figured that would be the preferred style
>> for this recipe.
>>
>>
>>> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
>>> wrote:
>>>
 The Linux kernel currently expects a single NVRAM file for BCM43430
 named brcmfmac43430-sdio.txt.

 Allow the machine to specify an override to link its module specific
 NVRAM to the filename expected by the kernel.

 Signed-off-by: Ryan Harkin 
 ---
  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
 
  1 file changed, 12 insertions(+)

 diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 index 8c54f28..b647abc 100644
 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 @@ -226,6 +226,18 @@ do_install() {
 ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
 ti-connectivity/* . )
  }

 +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
 +# softlink for the module specific NVRAM file to the filename expected
 +# by the Linux kernel
 +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
 ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
 +do_install_append_bcm43430-nvram-mur1dx() {
 +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
 brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
 +}
 +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
 "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
 +do_install_append_bcm43430-nvram-ap6212() {
 +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
 brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
 +}
 +

  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
   ${PN}-mt7601u-license ${PN}-mt7601u \
 --
 2.7.4


>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Martin Jansa]

cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt

is the same as

ln -sf brcmfmac43430-sdio.AP6212.txt ${D}${nonarch_base_libdir}/fir
mware/brcm/brcmfmac43430-sdio.txt

On Wed, Aug 22, 2018 at 6:47 PM Ryan Harkin  wrote:

>
>
> On 22 August 2018 at 17:41, Martin Jansa  wrote:
>
>> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
>> needed, just include the path in 2nd ln parameter.
>>
>
> I don't think that works, or at least, it doesn't work for me, so I may be
> doing something wrong. I'm also copying the example used in the
> do_install() a few lines up as I figured that would be the preferred style
> for this recipe.
>
>
>> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
>> wrote:
>>
>>> The Linux kernel currently expects a single NVRAM file for BCM43430
>>> named brcmfmac43430-sdio.txt.
>>>
>>> Allow the machine to specify an override to link its module specific
>>> NVRAM to the filename expected by the kernel.
>>>
>>> Signed-off-by: Ryan Harkin 
>>> ---
>>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
>>> 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> index 8c54f28..b647abc 100644
>>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>>> @@ -226,6 +226,18 @@ do_install() {
>>> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
>>> ti-connectivity/* . )
>>>  }
>>>
>>> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
>>> +# softlink for the module specific NVRAM file to the filename expected
>>> +# by the Linux kernel
>>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
>>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>>> +do_install_append_bcm43430-nvram-mur1dx() {
>>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>>> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
>>> +}
>>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
>>> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>>> +do_install_append_bcm43430-nvram-ap6212() {
>>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
>>> +}
>>> +
>>>
>>>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>>>   ${PN}-mt7601u-license ${PN}-mt7601u \
>>> --
>>> 2.7.4
>>>
>>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ltp: Fix ftest06 too small file path string

[zhe.he]

From: He Zhe 

The name string is too small to contain normal full path names and causes
the following failure.

"ftest06 2  TFAIL  :  ftest06.c:223: Can't chdir(): errno=ENOENT(2): No 
such file or directory"

Signed-off-by: He Zhe 
---
 ...est06.c-Fix-too-small-name-string-and-rel.patch | 34 ++
 meta/recipes-extended/ltp/ltp_20180515.bb  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch
 
b/meta/recipes-extended/ltp/ltp/0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch
new file mode 100644
index 000..407d98e
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch
@@ -0,0 +1,34 @@
+From baeef026f80e19a634a4096e97286419aca1cf68 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Thu, 23 Aug 2018 00:22:04 +0800
+Subject: [PATCH] fs/ftest/ftest06.c: Fix too small name string and related
+ failure
+
+The name string is too small to contain normal full path names and causes
+the following failure.
+
+"ftest06 2  TFAIL  :  ftest06.c:223: Can't chdir(): errno=ENOENT(2): No 
such file or directory"
+
+Upstream-Status: Submitted [ltp-l...@lists.sourceforge.net]
+
+Signed-off-by: He Zhe 
+---
+ testcases/kernel/fs/ftest/ftest06.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/testcases/kernel/fs/ftest/ftest06.c 
b/testcases/kernel/fs/ftest/ftest06.c
+index 2ca7c88..b434067 100644
+--- a/testcases/kernel/fs/ftest/ftest06.c
 b/testcases/kernel/fs/ftest/ftest06.c
+@@ -100,7 +100,7 @@ static char *fstyp;
+ int main(int ac, char *av[])
+ {
+   int pid, child, status, count, k, j;
+-  char name[3];
++  char name[MAXPATHLEN];
+ 
+   int lc;
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index 8f64d7b..978d3cd 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -49,6 +49,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0039-commands-ar01-Fix-for-test-in-deterministic-mode.patch \

file://0040-read_all-Define-FNM_EXTMATCH-if-not-already-like-und.patch \

file://0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch \
+   
file://0042-fs-ftest-ftest06.c-Fix-too-small-name-string-and-rel.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

On 22 August 2018 at 17:41, Martin Jansa  wrote:

> The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
> needed, just include the path in 2nd ln parameter.
>

I don't think that works, or at least, it doesn't work for me, so I may be
doing something wrong. I'm also copying the example used in the
do_install() a few lines up as I figured that would be the preferred style
for this recipe.


> On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin 
> wrote:
>
>> The Linux kernel currently expects a single NVRAM file for BCM43430
>> named brcmfmac43430-sdio.txt.
>>
>> Allow the machine to specify an override to link its module specific
>> NVRAM to the filename expected by the kernel.
>>
>> Signed-off-by: Ryan Harkin 
>> ---
>>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
>> 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> index 8c54f28..b647abc 100644
>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
>> @@ -226,6 +226,18 @@ do_install() {
>> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
>> ti-connectivity/* . )
>>  }
>>
>> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
>> +# softlink for the module specific NVRAM file to the filename expected
>> +# by the Linux kernel
>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>> +do_install_append_bcm43430-nvram-mur1dx() {
>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
>> +}
>> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
>> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
>> +do_install_append_bcm43430-nvram-ap6212() {
>> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
>> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
>> +}
>> +
>>
>>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>>   ${PN}-mt7601u-license ${PN}-mt7601u \
>> --
>> 2.7.4
>>
>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Martin Jansa]

The "cd ${D}${nonarch_base_libdir}/firmware/brcm/" doesn't seem to be
needed, just include the path in 2nd ln parameter.

On Wed, Aug 22, 2018 at 6:30 PM Ryan Harkin  wrote:

> The Linux kernel currently expects a single NVRAM file for BCM43430
> named brcmfmac43430-sdio.txt.
>
> Allow the machine to specify an override to link its module specific
> NVRAM to the filename expected by the kernel.
>
> Signed-off-by: Ryan Harkin 
> ---
>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12
> 
>  1 file changed, 12 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index 8c54f28..b647abc 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -226,6 +226,18 @@ do_install() {
> ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
> ti-connectivity/* . )
>  }
>
> +# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
> +# softlink for the module specific NVRAM file to the filename expected
> +# by the Linux kernel
> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = "
> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> +do_install_append_bcm43430-nvram-mur1dx() {
> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
> +}
> +FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 =
> "${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
> +do_install_append_bcm43430-nvram-ap6212() {
> +   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
> +}
> +
>
>  PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-mt7601u-license ${PN}-mt7601u \
> --
> 2.7.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Ryan Harkin]

The Linux kernel currently expects a single NVRAM file for BCM43430
named brcmfmac43430-sdio.txt.

Allow the machine to specify an override to link its module specific
NVRAM to the filename expected by the kernel.

Signed-off-by: Ryan Harkin 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 8c54f28..b647abc 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -226,6 +226,18 @@ do_install() {
( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . )
 }
 
+# Adding bcm43430-nvram-{module type} to MACHINEOVERRIDES will create a
+# softlink for the module specific NVRAM file to the filename expected
+# by the Linux kernel
+FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-mur1dx = " 
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
+do_install_append_bcm43430-nvram-mur1dx() {
+   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf 
brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
+}
+FILES_${PN}-bcm43430-nvram_append_bcm43430-nvram-ap6212 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt"
+do_install_append_bcm43430-nvram-ap6212() {
+   ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf 
brcmfmac43430-sdio.AP6212.txt brcmfmac43430-sdio.txt)
+}
+
 
 PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-mt7601u-license ${PN}-mt7601u \
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC 1/3] linux-firmware: upgrade to 1d17c18 revision

[Ryan Harkin]

Following changes are applied:

1d17c18 linux-firmware: add firmware for mhdp8546
c2e0d14 qed: Add firmware 8.37.7.0
f1b95fe linux-firmware:Update firmware patch for Intel Bluetooth 7265
8813230 linux-firmware: Update firmware file for Intel Bluetooth,9560
c2d8f1b linux-firmware: Update firmware file for Intel Bluetooth,9260
9767096 linux-firmware: Update firmware file for Intel Bluetooth,8265
41bdd3b linux-firmware: Update firmware patch for Intel Bluetooth 8260
fdd3468 linux-firmware: add firmware for mt76x0
eee8208 Merge commit 'c4883661c7eeedd061eb3b483135b47dab39a88d' of
6ae7a5b qcom: update venus firmware files for v5.2
c488366 nfp: update Agilio SmartNIC flower firmware to rev AOTC-2.9.A.31
7b5835f linux-firmware: add firmware for mt76x2u
3a5103f wl18xx: update firmware file 8.9.0.0.79
b01151b Mellanox: Add new mlxsw_spectrum firmware 13.1702.6
0ff06f2 WHENCE: Remove reference to amdgpu/vegam_me_2.bin
3fcf221 linux-firmware: mediatek: add MT7622 Bluetooth firmwares and
c8d6903 brcm: add 43430 based AP6212 and 1DX NVRAM
fad829d Merge git://git.marvell.com/mwifiex-firmware
0ced724 linux-firmware: update Marvell USB8801 B0 firmware image
8d69bab amdgpu: update copyright date
153a51e amdgpu: add initial VegaM firmware
10e2971 amdgpu: sync up vega10 firmware with 18.20 release
4b05dee amdgpu: sync up raven firmware with 18.20 release
aeec108 amdgpu: sync up polaris12 firmware with 18.20 release
5408150 amdgpu: sync up polaris11 firmware with 18.20 release
34116bf amdgpu: sync up polaris10 firmware with 18.20 release
a8a2884 amdgpu: sync up verde firmware with 18.20 release
bea8c7f amdgpu: sync up pitcairn firmware with 18.20 release
d47f956 amdgpu: sync up tahiti firmware with 18.20 release
1f92e00 amdgpu: sync up oland firmware with 18.20 release
effed45 amdgpu: sync up hainan firmware with 18.20 release
d50a667 amdgpu: sync up kaveri firmware with 18.20 release
5b8eca3 amdgpu: sync up mullins firmware with 18.20 release
b4b5726 amdgpu: sync up kabini firmware with 18.20 release
fc80838 amdgpu: sync up hawaii firmware with 18.20 release
5350953 amdgpu: sync up bonaire firmware with 18.20 release
8c96b0d WHENCE: Fix typo Version
6213586 cxgb4: update firmware to revision 1.20.8.0

Signed-off-by: Ryan Harkin 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 69f9a2a..4e0f1cc 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -66,7 +66,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 \
 file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
-file://LICENSE.amdgpu;md5=0aa3c2f3e736af320a08a3aeeccecf29 \
+file://LICENSE.amdgpu;md5=88b865bc74f3ffcc54640b4ea8540b46 \
 file://LICENSE.amd-ucode;md5=3c5399dc9148d7f0e1f41e34b69cf14f \
 file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
 file://LICENSE.atmel;md5=aa74ac0c60595dee4d4e239107ea77a3 \
@@ -120,7 +120,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
 file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=eaaf310bac02fee05ea1b334f58c5caf \
+file://WHENCE;md5=feb25f3efdbe10fcc121005d02d407d6 \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -184,7 +184,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
 NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
-SRCREV = "d1147327232ec4616a66ab898df84f9700c816c1"
+SRCREV = "1d17c18226c2ddf5bc127b3f934cfa88e0c0c29f"
 PE = "1"
 PV = "0.0+git${SRCPV}"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC 2/3] linux-firmware: add BCM43430 nvram files

[Ryan Harkin]

Add the new BCM43430 NVRAM files into the recipe.

Signed-off-by: Ryan Harkin 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 4e0f1cc..8c54f28 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -255,6 +255,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-bcm43362 \
  ${PN}-bcm4339 \
  ${PN}-bcm43430 \
+ ${PN}-bcm43430-nvram \
  ${PN}-bcm43430a0 \
  ${PN}-bcm43455 \
  ${PN}-bcm4350 \
@@ -649,6 +650,9 @@ FILES_${PN}-bcm-0bb4-0306 = 
"${nonarch_base_libdir}/firmware/brcm/BCM-0bb4-0306.
 FILES_${PN}-bcm43340 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac43340-sdio.bin"
 FILES_${PN}-bcm43362 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac43362-sdio.bin"
 FILES_${PN}-bcm43430 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin"
+FILES_${PN}-bcm43430-nvram = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt \
+  ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt \
+"
 FILES_${PN}-bcm4354 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4354-sdio.bin"
 FILES_${PN}-bcm4356-pcie = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4356-pcie.bin"
 FILES_${PN}-bcm4373 = 
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.bin \
@@ -662,6 +666,8 @@ RDEPENDS_${PN}-bcm43340 += "${PN}-cypress-license"
 LICENSE_${PN}-bcm43362 = "Firmware-cypress"
 RDEPENDS_${PN}-bcm43362 += "${PN}-cypress-license"
 LICENSE_${PN}-bcm43430 = "Firmware-cypress"
+LICENSE_${PN}-bcm43430-nvram = "Firmware-GPLv2"
+RDEPENDS_${PN}-bcm43430-nvram += "${PN}-gplv2-license"
 RDEPENDS_${PN}-bcm43430 += "${PN}-cypress-license"
 LICENSE_${PN}-bcm4354 = "Firmware-cypress"
 RDEPENDS_${PN}-bcm4354 += "${PN}-cypress-license"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC 0/3] Adding BCM43430 NVRAM files

[Ryan Harkin]

[Resending because I sent to the wrong email address for the oe-core
mailing list]

NVRAM files for the 43430 modules have been committed into the upstream
Linux firmware repo. I'd like to add these files into the linux-firmware
recipe.

The following files exist upstream on kernel.org:

- brcm/brcmfmac43430-sdio.AP6212.txt
- brcm/brcmfmac43430-sdio.MUR1DX.txt

The AP6212 and MUR1DX are the module types for variants of the 43430
chips.

The first patch is a simple update to the latest upstream. I guess
someone else will commit a similar change before I get to it, but for
now, I need to make the update to test my changes, so I thought I'd send
the patch with my RFC series.

The second patch adds both NVRAM files into a single new variable.
Ideally, the Linux kernel will be extended detect the module type, so
having all the NVRAM files in /lib/firmware/brcm seems like a sensible
thing to do. But advice here is appreciated. Perhaps I should have a
separate variable for each file and allow the machine config to choose
which configs to include in the filesystem, similar to how the .bin
files are included since Martin Jansa's change?

The 3rd patch is trickier, I think. At the moment, the Linux kernel
expects there to be only one NVRAM file, named brcmfmac43430-sdio.txt.
So to make the system "just work", it seems sensible to provide a way to
softlink the module specific NVRAM to the generic filename.

I'm trying to avoid each machine type having to define a softlink
_append in its own config. Many different machines can use the same
module type, for example.  I'm just not convinced that the way I've done
it is appropriate. eg. I don't like the usage of MACHINEOVERRIDE, or the
variable name I've chosen. I'd hoped to do it using a
MACHINE_EXTRA_RRECOMMENDS, but I'm not sure if that is possible. Again,
advice is appreciated.

Ryan Harkin (3):
  linux-firmware: upgrade to 1d17c18 revision
  linux-firmware: add BCM43430 nvram files
  linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

 .../linux-firmware/linux-firmware_git.bb   | 23 +++---
 1 file changed, 20 insertions(+), 3 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] libxml-parser-perl: fix "...contains bad RPATH"

[Richard Purdie]

On Wed, 2018-08-22 at 11:04 +0200, Jens Rehsack wrote:
> The perl distribution "XML-Parser" relies for configuration
> on the tooling of Devel::CheckLib - which is not aware of
> sysroot locations nor of reasonable compiler/link definitions
> from outside.
> 
> This causes
> 
> ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA Issue:
> package libxml-parser-perl contains bad RPATH
> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-
> r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-
> linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-
> perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
> package libxml-parser-perl contains bad RPATH
> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-
> r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-
> linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-
> perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
> [rpaths]
> ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA run found
> fatal errors. Please consider fixing them.
> ERROR: libxml-parser-perl-2.44-r0 do_package_qa: Function failed:
> do_package_qa
> 
> It's strongly encouraged to the maintainer @toddr to rework the
> toolchain for up to date environments.
> 
> Signed-off-by: Jens Rehsack 
> ---
>  meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb | 10
> +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
> b/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
> index c5e0ae6769..4494e2286c 100644
> --- a/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
> +++ b/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
> @@ -18,8 +18,16 @@ inherit cpan ptest-perl
>  
>  # fix up sub MakeMaker project as arguments don't get propagated
> though
>  # see https://rt.cpan.org/Public/Bug/Display.html?id=28632
> +do_configure_append_class-target() {
> + sed -E \
> + -e 's:-L${STAGING_LIBDIR}::g' -e 's:-
> I${STAGING_INCDIR}::g' \
> + -e 's:LD_RUN_PATH ?= ?"?[^"]*"?::g' \
> + -i Makefile Expat/Makefile
> +}
> +
>  do_configure_append() {
> - sed 's:--sysroot=.*\(\s\|$\):--sysroot=${STAGING_DIR_TARGET}
> :g' -i Makefile Expat/Makefile
> + sed -e 's:--sysroot=.*\(\s\|$\):
> --sysroot=${STAGING_DIR_TARGET} :g' \
> + -i Makefile Expat/Makefile
>   sed 's:^FULL_AR = .*:FULL_AR = ${AR}:g' -i Expat/Makefile
>   # make sure these two do not build in parallel
>   sed 's!^$(INST_DYNAMIC):!$(INST_DYNAMIC): $(BOOTSTRAP)!' -i
> Expat/Makefile

Sorry, this fails to build the nativesdk version:

https://autobuilder.yocto.io/builders/nightly-x86/builds/1261/steps/Building%20Toolchain%20Images/logs/stdio

I suspect you need to strip the RPATH in the nativesdk case...

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC] Yocto Project Bug 12372 - Automate the execution of pTest with LAVA

[Yang Wang]

On 18-08-22 02:51 AM, Nicolas Dechesne wrote:

> hi,
>
> On Wed, Aug 22, 2018 at 4:25 AM Randy MacLeod
>  wrote:
>> On 08/21/2018 11:04 AM, Wang, Yang (Young) wrote:
>>> Hi All,
>>>
>>> I'm working on this ticket:
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12372
>> Thanks for investigating the bug/enhancement and posting your thoughts.
>> I'm jumping in without much expertise to try to get the ball rolling.
>>
>>> As far as I know, the following are all true nowadays:
>>> - Ptest needs to be run on real hardware and it takes few hours to finish
>>> - Ptest can be run within OEQA, it can also be run independently
>>> - LAVA is a good open source test  framework which:
>>> - can manage both real hardware and different kinds of simulators as 
>>> the test devices
>>> - provides well managed logging system and test reports
>>>
>>> How to automatically run Ptest? I think running it with LAVA is a good 
>>> solution, but ...
>>>
>>> LAVA is running as a server which can manage test jobs submitted to it, 
>>> here is a typical LAVA job:
>>> https://staging.validation.linaro.org/scheduler/job/231942/definition
>>> As you can see, it defines the device type, test images which will used, 
>>> the test cases and a lot of others.
>> That's a good clear format.
>>
>> I believe that what people are thinking is that we'd have:
>>
>> device_type: x86
>>
>> job_name: x86_64 oeqa
>> ...
>>
>> actions:
>> - deploy:
>>   ...
>>
>> - boot:
>> ...
>>
>> - test:
>>  timeout:
>>minutes: 2
>>  definitions:
>>   << some thing that makes the target and lava server wait for
>>  oeqa to run >>
>>name: oeqa-test
>>
>>> So the typical automatic way to run a test through LAVA is to write a 
>>> script which use a LAVA job template, replace images with the expected 
>>> ones, and then submit it to LAVA though a command, for example:
>>> $ lava-tool submit-job http://@ x86_64_ 
>>> job_oeqa-ptest.yaml
> This is more or less something that we are doing as part of our CI
> loop. The process is the following:
>
> 1. fetch layers updates
> 2. make a new build for one or more $MACHINE
> 3. use LAVA job template to generate an actual LAVA job
> 4. run this LAVA job on the Linaro LAVA Board farm
>
> There is no integration into oe-core / bitbake, it is run outside of
> the OE builds.
This is clear, the test automation through LAVA needs to be done outside
of OE.
> You can check our ptest LAVA job from our most recent build:
> https://validation.linaro.org/scheduler/job/1890442
>
> The generated LAVA job is:
> https://validation.linaro.org/scheduler/job/1890442/definition
>
> The job deals with all the flashing/management of the device to test
> (a dragonboard 820c in this specific example), so there is a bit of
> boiler plate , but the base template for running ptest can be found
> here:
>
> https://git.linaro.org/ci/job/configs.git/tree/lt-qcom/lava-job-definitions/boards/template-ptest.yaml
>
> which itself points the the LAVA job definition for ptest:
>
> https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ptest
>
> This is where LAVA communicates and manages how to run ptests and get
> status from each test.
>
> And finally... you can view the test results for this ptest run in LAVA:
>
> https://validation.linaro.org/results/1890442/0_linux-ptest
My private test automation framework is doing the similar job on daily
basis.

So there are some preconditions of doing test automation through LAVA
publicly:
1. Select a public LAVA server with an accessible account
2. Exactly know which type of hardware we would like to use, and that
has to be set in the LAVA job
    - It doesn't need to set a specific board since LAVA supports
device-types, for example:
https://validation.linaro.org/scheduler/device_types
3. Devices under this specific device-type need to be maintained by
someone, if they don't work, our tests will fail all the time

So, go back to the original ticket, we can definitely create some
scripts to run Ptest automatically through LAVA, but specific settings
of LAVA server and device-type have to be there as well. I'm concerned
if this is what the ticket reporter would like to get.

Thanks,
-Yang Wang
>> That would still work given the above oeqa job.
>>
>> No doubt there's additional glue code that would
>> be nice to write that would allow automatically creating
>> the lava yaml that boots the system into a state where oeqa
>> code takes over.
> I think most of what needs to be created is there in all the links I
> shared above. This is what we came up with , and it is not integrated
> with oeqa. But this can be used as a baseline at least.
>
>> I've never used it and only just found the code but
>> I bet that adding another controller to:
>>
>> git://git.yoctoproject.org/meta-yocto
>>
>> $ ls  meta-yocto-bsp/lib/oeqa/controllers/
>> beaglebonetarget.py  edgeroutertarget.py  grubtarget.py  __init__.py
>>
>> is what would make sense.
>>
>>> This command will return a job id 

Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

[Khem Raj]

On Wed, Aug 22, 2018 at 7:57 AM  wrote:
>
> On Wed, 2018-08-22 at 15:39 +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Aug 22, 2018 at 3:37 PM 
> > wrote:
> > > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > > /libx32/ld-linux-x32.so.
> > >
> > > I just looked at what the function is doing and its broken. What is
> > > DEFAULTTUNE set to in your build?
> >
> > DEFAULTTUNE="dbfp4"
>
> As I suspected.
>
> Try applying:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=d69f0127b44a5216dd21ad972d6f2b2e4cda6d13
>

this makes it a lot better thanks for doing it. Perhaps we should check for
libc-glibc override for glibc case and throw an error if no conditions are met
it might affect nativesdk version probably.

> and
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=95aa56ae11852c100be68d13aaffa9c83273b46b
>
> and then seen if that fixes things.
>
> Cheers,
>
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 33/34] perl: CVE-2018-12015

[Jagadeesh Krishnanjanappa]

Remove existing files before overwriting them

Archive should extract only the latest same-named entry.
Extracted regular file should not be writtent into existing block
device (or any other one).

https://rt.cpan.org/Ticket/Display.html?id=125523

Affects perl <= 5.26.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../perl/perl/CVE-2018-12015.patch | 48 ++
 meta/recipes-devtools/perl/perl_5.24.1.bb  |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-12015.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
new file mode 100644
index 000..a2b0109
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
@@ -0,0 +1,48 @@
+From ae65651eab053fc6dc4590dbb863a268215c1fc5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 8 Jun 2018 11:45:40 +0100
+Subject: [PATCH] [PATCH] Remove existing files before overwriting them
+
+Archive should extract only the latest same-named entry.
+Extracted regular file should not be writtent into existing block
+device (or any other one).
+
+https://rt.cpan.org/Ticket/Display.html?id=125523
+
+CVE: CVE-2018-12015
+Upstream-Status: Backport 
[https://github.com/jib/archive-tar-new/commit/ae65651eab053fc6dc4590dbb863a268215c1fc5]
+
+Signed-off-by: Chris 'BinGOs' Williams 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/Archive/Tar.pm | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/cpan/Archive-Tar/lib/Archive/Tar.pm 
b/cpan/Archive-Tar/lib/Archive/Tar.pm
+index 6244369..a83975f 100644
+--- a/cpan/Archive-Tar/lib/Archive/Tar.pm
 b/cpan/Archive-Tar/lib/Archive/Tar.pm
+@@ -845,6 +845,20 @@ sub _extract_file {
+ return;
+ }
+ 
++### If a file system already contains a block device with the same name as
++### the being extracted regular file, we would write the file's content
++### to the block device. So remove the existing file (block device) now.
++### If an archive contains multiple same-named entries, the last one
++### should replace the previous ones. So remove the old file now.
++### If the old entry is a symlink to a file outside of the CWD, the new
++### entry would create a file there. This is CVE-2018-12015
++### .
++if (-l $full || -e _) {
++  if (!unlink $full) {
++  $self->_error( qq[Could not remove old file '$full': $!] );
++  return;
++  }
++}
+ if( length $entry->type && $entry->is_file ) {
+ my $fh = IO::File->new;
+ $fh->open( $full, '>' ) or (
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb 
b/meta/recipes-devtools/perl/perl_5.24.1.bb
index aec30c8..8dfe34a 100644
--- a/meta/recipes-devtools/perl/perl_5.24.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
@@ -72,6 +72,7 @@ SRC_URI += " \
 file://CVE-2018-6798-2.patch \
 file://CVE-2018-6797.patch \
 file://CVE-2018-6913.patch \
+file://CVE-2018-12015.patch \
 "
 
 # Fix test case issues
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 34/34] libgcrypt: CVE-2018-0495

[Jagadeesh Krishnanjanappa]

ecc: Add blinding for ECDSA.

* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Blind secret D with
randomized nonce B.

--

CVE-id: CVE-2018-0495

Affects libgcrypt < 1.7.10 and libgcrypt < 1.8.3

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libgcrypt/files/CVE-2018-0495.patch| 76 ++
 meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb  |  1 +
 2 files changed, 77 insertions(+)
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch

diff --git a/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch 
b/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch
new file mode 100644
index 000..c16bd3a
--- /dev/null
+++ b/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch
@@ -0,0 +1,76 @@
+From 9010d1576e278a4274ad3f4aa15776c28f6ba965 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka 
+Date: Wed, 13 Jun 2018 15:28:58 +0900
+Subject: [PATCH] ecc: Add blinding for ECDSA.
+
+* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Blind secret D with
+randomized nonce B.
+
+--
+
+Reported-by: Keegan Ryan 
+CVE-id: CVE-2018-0495
+
+Upstream-Status: Backport 
[http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=9010d1576e278a4274ad3f4aa15776c28f6ba965]
+
+Signed-off-by: NIIBE Yutaka 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ cipher/ecc-ecdsa.c | 20 ++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
+index 1484830b..140e8c09 100644
+--- a/cipher/ecc-ecdsa.c
 b/cipher/ecc-ecdsa.c
+@@ -50,6 +50,8 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key *skey,
+   const void *abuf;
+   unsigned int abits, qbits;
+   mpi_ec_t ctx;
++  gcry_mpi_t b;/* Random number needed for blinding.  */
++  gcry_mpi_t bi;   /* multiplicative inverse of B.*/
+ 
+   if (DBG_CIPHER)
+ log_mpidump ("ecdsa sign hash  ", input );
+@@ -61,6 +63,15 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+   if (rc)
+ return rc;
+ 
++  b  = mpi_snew (qbits);
++  bi = mpi_snew (qbits);
++  do
++{
++  _gcry_mpi_randomize (b, qbits, GCRY_WEAK_RANDOM);
++  mpi_mod (b, b, skey->E.n);
++}
++  while (!mpi_invm (bi, b, skey->E.n));
++
+   k = NULL;
+   dr = mpi_alloc (0);
+   sum = mpi_alloc (0);
+@@ -115,8 +126,11 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+ }
+   while (!mpi_cmp_ui (r, 0));
+ 
+-  mpi_mulm (dr, skey->d, r, skey->E.n); /* dr = d*r mod n  */
+-  mpi_addm (sum, hash, dr, skey->E.n);  /* sum = hash + (d*r) mod n  */
++  mpi_mulm (dr, b, skey->d, skey->E.n);
++  mpi_mulm (dr, dr, r, skey->E.n);  /* dr = d*r mod n (blinded with 
b) */
++  mpi_mulm (sum, b, hash, skey->E.n);
++  mpi_addm (sum, sum, dr, skey->E.n);   /* sum = hash + (d*r) mod n  
(blinded with b) */
++  mpi_mulm (sum, bi, sum, skey->E.n);   /* undo blinding by b^-1 */
+   mpi_invm (k_1, k, skey->E.n); /* k_1 = k^(-1) mod n  */
+   mpi_mulm (s, k_1, sum, skey->E.n);/* s = k^(-1)*(hash+(d*r)) mod n 
*/
+ }
+@@ -129,6 +143,8 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+ }
+ 
+  leave:
++  mpi_free (b);
++  mpi_free (bi);
+   _gcry_mpi_ec_free (ctx);
+   point_free ();
+   mpi_free (x);
+-- 
+2.13.3
+
diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
index 02982f0..3d189f5 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
@@ -22,6 +22,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \

file://0004-tests-Makefile.am-fix-undefined-reference-to-pthread.patch \
file://0005-ecc-Add-input-validation-for-X25519.patch \

file://0006-Fix-building-AArch32-CE-implementations-when-target-.patch \
+   file://CVE-2018-0495.patch \
 "
 SRC_URI[md5sum] = "110ce4352f9ea6f560bdc6c5644ae93c"
 SRC_URI[sha256sum] = 
"f6e470b7f2d3a703e8747f05a8c19d9e10e26ebf2d5f3d71ff75a40f504e12ee"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 31/34] git: CVE-2018-11235

[Jagadeesh Krishnanjanappa]

submodule-config: verify submodule names as paths

Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).

Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:

  1. What should the allowed syntax be?

 It's tempting to reuse verify_path(), since submodule
 names typically come from in-repo paths. But there are
 two reasons not to:

   a. It's technically more strict than what we need, as
  we really care only about breaking out of the
  $GIT_DIR/modules/ hierarchy.  E.g., having a
  submodule named "foo/.git" isn't actually
  dangerous, and it's possible that somebody has
  manually given such a funny name.

   b. Since we'll eventually use this checking logic in
  fsck to prevent downstream repositories, it should
  be consistent across platforms. Because
  verify_path() relies on is_dir_sep(), it wouldn't
  block "foo\..\bar" on a non-Windows machine.

  2. Where should we enforce it? These days most of the
 .gitmodules reads go through submodule-config.c, so
 I've put it there in the reading step. That should
 cover all of the C code.

 We also construct the name for "git submodule add"
 inside the git-submodule.sh script. This is probably
 not a big deal for security since the name is coming
 from the user anyway, but it would be polite to remind
 them if the name they pick is invalid (and we need to
 expose the name-checker to the shell anyway for our
 test scripts).

 This patch issues a warning when reading .gitmodules
 and just ignores the related config entry completely.
 This will generally end up producing a sensible error,
 as it works the same as a .gitmodules file which is
 missing a submodule entry (so "submodule update" will
 barf, but "git clone --recurse-submodules" will print
 an error but not abort the clone.

 There is one minor oddity, which is that we print the
 warning once per malformed config key (since that's how
 the config subsystem gives us the entries). So in the
 new test, for example, the user would see three
 warnings. That's OK, since the intent is that this case
 should never come up outside of malicious repositories
 (and then it might even benefit the user to see the
 message multiple times).

Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.

Affects: git < 2.13.7 and  git < 2.14.4 and git < 2.15.2 and git < 2.16.4 and
 git < 2.17.1

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../git/files/CVE-2018-11235.patch | 288 +
 meta/recipes-devtools/git/git.inc  |   3 +-
 2 files changed, 290 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/files/CVE-2018-11235.patch

diff --git a/meta/recipes-devtools/git/files/CVE-2018-11235.patch 
b/meta/recipes-devtools/git/files/CVE-2018-11235.patch
new file mode 100644
index 000..b774d2f
--- /dev/null
+++ b/meta/recipes-devtools/git/files/CVE-2018-11235.patch
@@ -0,0 +1,288 @@
+From 0383bbb9015898cbc79abd7b64316484d7713b44 Mon Sep 17 00:00:00 2001
+From: Jeff King 
+Date: Mon, 30 Apr 2018 03:25:25 -0400
+Subject: [PATCH] submodule-config: verify submodule names as paths
+
+Submodule "names" come from the untrusted .gitmodules file,
+but we blindly append them to $GIT_DIR/modules to create our
+on-disk repo paths. This means you can do bad things by
+putting "../" into the name (among other things).
+
+Let's sanity-check these names to avoid building a path that
+can be exploited. There are two main decisions:
+
+  1. What should the allowed syntax be?
+
+ It's tempting to reuse verify_path(), since submodule
+ names typically come from in-repo paths. But there are
+ two reasons not to:
+
+   a. It's technically more strict than what we need, as
+  we really care only about breaking out of the
+  $GIT_DIR/modules/ hierarchy.  E.g., having a
+  submodule named "foo/.git" isn't actually
+  dangerous, and it's possible that somebody has
+  manually given such a funny name.
+
+   b. Since we'll eventually use this checking logic in
+  fsck to prevent downstream repositories, it should
+  be consistent across platforms. Because
+  verify_path() relies on is_dir_sep(), it wouldn't
+  block "foo\..\bar" on a non-Windows machine.
+
+  2. Where should we enforce it? These days most of the
+ .gitmodules reads go through submodule-config.c, so
+ I've put it there in the reading step. That should
+ cover all of the C code.
+
+ We also construct the name for "git 

[OE-core] [ROCKO][PATCH V3 32/34] openssl: CVE-2018-0732

[Jagadeesh Krishnanjanappa]

Reject excessively large primes in DH key generation.

CVE-2018-0732

Affects openssl 1.0.2 to 1.0.2o

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../openssl/openssl-1.0.2o/CVE-2018-0732.patch | 46 ++
 .../recipes-connectivity/openssl/openssl_1.0.2o.bb |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch 
b/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch
new file mode 100644
index 000..d4d0bb4
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch
@@ -0,0 +1,46 @@
+From 3984ef0b72831da8b3ece4745cac4f8575b19098 Mon Sep 17 00:00:00 2001
+From: Guido Vranken 
+Date: Mon, 11 Jun 2018 19:38:54 +0200
+Subject: [PATCH] Reject excessively large primes in DH key generation.
+
+CVE: CVE-2018-0732
+
+Signed-off-by: Guido Vranken 
+
+(cherry picked from commit 91f7361f47b082ae61ffe1a7b17bb2adf213c7fe)
+
+Reviewed-by: Tim Hudson 
+Reviewed-by: Matt Caswell 
+(Merged from https://github.com/openssl/openssl/pull/6457)
+
+Upstream-Status: Backport 
[https://github.com/openssl/openssl/commit/ea7abeeabf92b7aca160bdd0208636d4da69f4f4]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ crypto/dh/dh_key.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/dh/dh_key.c b/crypto/dh/dh_key.c
+index 387558f146..f235e0d682 100644
+--- a/crypto/dh/dh_key.c
 b/crypto/dh/dh_key.c
+@@ -130,10 +130,15 @@ static int generate_key(DH *dh)
+ int ok = 0;
+ int generate_new_key = 0;
+ unsigned l;
+-BN_CTX *ctx;
++BN_CTX *ctx = NULL;
+ BN_MONT_CTX *mont = NULL;
+ BIGNUM *pub_key = NULL, *priv_key = NULL;
+ 
++if (BN_num_bits(dh->p) > OPENSSL_DH_MAX_MODULUS_BITS) {
++DHerr(DH_F_GENERATE_KEY, DH_R_MODULUS_TOO_LARGE);
++return 0;
++}
++
+ ctx = BN_CTX_new();
+ if (ctx == NULL)
+ goto err;
+-- 
+2.13.3
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
index 413ebf3..57912a1 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
@@ -41,6 +41,7 @@ SRC_URI += "file://find.pl;subdir=openssl-${PV}/util/ \
file://Use-SHA256-not-MD5-as-default-digest.patch \
file://0001-Fix-build-with-clang-using-external-assembler.patch \
file://0001-openssl-force-soft-link-to-avoid-rare-race.patch \
+   file://CVE-2018-0732.patch \
"
 
 SRC_URI_append_class-target = "\
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 30/34] flac: CVE-2017-6888

[Jagadeesh Krishnanjanappa]

stream_decoder.c: Fix a memory leak

Leak reported by Secunia Research.

Affects flac = 1.3.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../flac/files/CVE-2017-6888.patch | 31 ++
 meta/recipes-multimedia/flac/flac_1.3.2.bb |  3 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/flac/files/CVE-2017-6888.patch

diff --git a/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch 
b/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch
new file mode 100644
index 000..389ab96
--- /dev/null
+++ b/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch
@@ -0,0 +1,31 @@
+From 4f47b63e9c971e6391590caf00a0f2a5ed612e67 Mon Sep 17 00:00:00 2001
+From: Erik de Castro Lopo 
+Date: Sat, 8 Apr 2017 18:34:49 +1000
+Subject: [PATCH] stream_decoder.c: Fix a memory leak
+
+Leak reported by Secunia Research.
+CVE: CVE-2017-6888
+Upstream-Status: Backport 
[https://git.xiph.org/?p=flac.git;a=commitdiff;h=4f47b63e9c971e6391590caf00a0f2a5ed612e67]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/libFLAC/stream_decoder.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
+index 14d5fe7f..a5527511 100644
+--- a/src/libFLAC/stream_decoder.c
 b/src/libFLAC/stream_decoder.c
+@@ -1753,6 +1753,9 @@ FLAC__bool 
read_metadata_vorbiscomment_(FLAC__StreamDecoder *decoder, FLAC__Stre
+   }
+   memset (obj->comments[i].entry, 0, 
obj->comments[i].length) ;
+   if 
(!FLAC__bitreader_read_byte_block_aligned_no_crc(decoder->private_->input, 
obj->comments[i].entry, obj->comments[i].length)) {
++  /* Current i-th entry is bad, 
so we delete it. */
++  free (obj->comments[i].entry) ;
++  obj->comments[i].entry = NULL ;
+   obj->num_comments = i;
+   goto skip;
+   }
+-- 
+2.13.3
+
diff --git a/meta/recipes-multimedia/flac/flac_1.3.2.bb 
b/meta/recipes-multimedia/flac/flac_1.3.2.bb
index 8315ab5..028a429 100644
--- a/meta/recipes-multimedia/flac/flac_1.3.2.bb
+++ b/meta/recipes-multimedia/flac/flac_1.3.2.bb
@@ -14,7 +14,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING.FDL;md5=ad1419ecc56e060eccf8184a87c4285f \
 
file://include/FLAC/all.h;beginline=65;endline=70;md5=64474f2b22e9e77b28d8b8b25c983a48"
 DEPENDS = "libogg"
 
-SRC_URI = "http://downloads.xiph.org/releases/flac/${BP}.tar.xz;
+SRC_URI = "http://downloads.xiph.org/releases/flac/${BP}.tar.xz \
+   file://CVE-2017-6888.patch"
 
 SRC_URI[md5sum] = "454f1bfa3f93cc708098d7890d0499bd"
 SRC_URI[sha256sum] = 
"91cfc3ed61dc40f47f050a109b08610667d73477af6ef36dcad31c31a4a8d53f"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 29/34] wget: CVE-2018-0494

[Jagadeesh Krishnanjanappa]

Fix cookie injection (CVE-2018-0494)
* src/http.c (resp_new): Replace \r\n by space in continuation lines

Fixes #53763
 "Malicious website can write arbitrary cookie entries to cookie jar"

HTTP header parsing left the \r\n from continuation line intact.
The Set-Cookie code didn't check and could be tricked to write
\r\n into the cookie jar, allowing a server to generate cookies at will.

Affects wget < 1.19.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../0001-Fix-cookie-injection-CVE-2018-0494.patch  | 68 ++
 meta/recipes-extended/wget/wget_1.19.1.bb  |  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 
meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch

diff --git 
a/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch 
b/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch
new file mode 100644
index 000..ac163e6
--- /dev/null
+++ 
b/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch
@@ -0,0 +1,68 @@
+From 1fc9c95ec144499e69dc8ec76dbe07799d7d82cd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
+Date: Fri, 27 Apr 2018 10:41:56 +0200
+Subject: [PATCH] Fix cookie injection (CVE-2018-0494)
+
+* src/http.c (resp_new): Replace \r\n by space in continuation lines
+
+Fixes #53763
+ "Malicious website can write arbitrary cookie entries to cookie jar"
+
+HTTP header parsing left the \r\n from continuation line intact.
+The Set-Cookie code didn't check and could be tricked to write
+\r\n into the cookie jar, allowing a server to generate cookies at will.
+
+CVE: CVE-2018-0494
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/wget.git/commit/?id=1fc9c95ec144499e69dc8ec76dbe07799d7d82cd]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/http.c | 18 +-
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+diff --git a/src/http.c b/src/http.c
+index c8960f11..77bdbbed 100644
+--- a/src/http.c
 b/src/http.c
+@@ -613,9 +613,9 @@ struct response {
+resp_header_*.  */
+ 
+ static struct response *
+-resp_new (const char *head)
++resp_new (char *head)
+ {
+-  const char *hdr;
++  char *hdr;
+   int count, size;
+ 
+   struct response *resp = xnew0 (struct response);
+@@ -644,15 +644,23 @@ resp_new (const char *head)
+ break;
+ 
+   /* Find the end of HDR, including continuations. */
+-  do
++  for (;;)
+ {
+-  const char *end = strchr (hdr, '\n');
++  char *end = strchr (hdr, '\n');
++
+   if (end)
+ hdr = end + 1;
+   else
+ hdr += strlen (hdr);
++
++  if (*hdr != ' ' && *hdr != '\t')
++break;
++
++  // continuation, transform \r and \n into spaces
++  *end = ' ';
++  if (end > head && end[-1] == '\r')
++end[-1] = ' ';
+ }
+-  while (*hdr == ' ' || *hdr == '\t');
+ }
+   DO_REALLOC (resp->headers, size, count + 1, const char *);
+   resp->headers[count] = NULL;
+-- 
+2.13.3
+
diff --git a/meta/recipes-extended/wget/wget_1.19.1.bb 
b/meta/recipes-extended/wget/wget_1.19.1.bb
index 78bde95..3c484ce 100644
--- a/meta/recipes-extended/wget/wget_1.19.1.bb
+++ b/meta/recipes-extended/wget/wget_1.19.1.bb
@@ -1,6 +1,7 @@
 SRC_URI = "${GNU_MIRROR}/wget/wget-${PV}.tar.gz \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
file://CVE-2017-6508.patch \
+   file://0001-Fix-cookie-injection-CVE-2018-0494.patch \
   "
 
 SRC_URI[md5sum] = "87cea36b7161fd43e3fd51a4e8b89689"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 28/34] perl: CVE-2018-6913

[Jagadeesh Krishnanjanappa]

(perl #131844) fix various space calculation issues in
 pp_pack.c

- for the originally reported case, if the start/cur pointer is in the
  top 75% of the address space the add (cur) + glen addition would
  overflow, resulting in the condition failing incorrectly.

- the addition of the existing space used to the space needed could
  overflow, resulting in too small an allocation and a buffer overflow.

- the scaling for UTF8 could overflow.

- the multiply to calculate the space needed for many items could
  overflow.

For the first case, do a space calculation without making new pointers.

For the other cases, detect the overflow and croak if there's an
overflow.

Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.

For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.

Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.

One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.

Note: changed
plan tests => 14713;
to
plan tests => 14712;
in a/t/op/pack.t
to apply this patch on perl 5.24.1.

Affects perl < 5.26.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/perl/perl/CVE-2018-6913.patch | 153 +
 meta/recipes-devtools/perl/perl_5.24.1.bb  |   1 +
 2 files changed, 154 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6913.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch
new file mode 100644
index 000..5df47dc
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch
@@ -0,0 +1,153 @@
+From f17fed5006177dce8ac48229c424a2da0d6ba492 Mon Sep 17 00:00:00 2001
+From: Tony Cook 
+Date: Tue, 8 Aug 2017 09:32:58 +1000
+Subject: [PATCH] (perl #131844) fix various space calculation issues in
+ pp_pack.c
+
+- for the originally reported case, if the start/cur pointer is in the
+  top 75% of the address space the add (cur) + glen addition would
+  overflow, resulting in the condition failing incorrectly.
+
+- the addition of the existing space used to the space needed could
+  overflow, resulting in too small an allocation and a buffer overflow.
+
+- the scaling for UTF8 could overflow.
+
+- the multiply to calculate the space needed for many items could
+  overflow.
+
+For the first case, do a space calculation without making new pointers.
+
+For the other cases, detect the overflow and croak if there's an
+overflow.
+
+Originally this used Size_t_MAX as the maximum size of a memory
+allocation, but for -DDEBUGGING builds realloc() throws a panic for
+allocations over half the address space in size, changing the error
+reported for the allocation.
+
+For non-DEBUGGING builds the Size_t_MAX limit has the small chance
+of finding a system that has 3GB of contiguous space available, and
+allocating that space, which could be a denial of servce in some cases.
+
+Unfortunately changing the limit to half the address space means that
+the exact case with the original issue can no longer occur, so the
+test is no longer testing against the address + length issue that
+caused the original problem, since the allocation is failing earlier.
+
+One option would be to change the test so the size request by pack is
+just under 2GB, but this has a higher (but still low) probability that
+the system has the address space available, and will actually try to
+allocate the memory, so let's not do that.
+
+Note: changed 
+plan tests => 14713;
+to 
+plan tests => 14712;
+in a/t/op/pack.t
+to apply this patch on perl 5.24.1.
+
+CVE: CVE-2018-6913
+Upstream-Status: Backport 
[https://perl5.git.perl.org/perl.git/commitdiff/f17fed5006177dce8ac48229c424a2da0d6ba492]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ pp_pack.c   | 25 +
+ t/op/pack.t | 24 +++-
+ 2 files changed, 44 insertions(+), 5 deletions(-)
+
+diff --git a/pp_pack.c b/pp_pack.c
+index 8937d6d715..5e9cc64301 100644
+--- a/pp_pack.c
 b/pp_pack.c
+@@ -357,11 +357,28 @@ STMT_START { 
\
+ } \
+ } STMT_END
+ 
++#define SAFE_UTF8_EXPAND(var) \
++STMT_START {  \
++if ((var) > SSize_t_MAX / 

[OE-core] [ROCKO][PATCH V3 27/34] perl: CVE-2018-6797

[Jagadeesh Krishnanjanappa]

(perl #132227) restart a node if we change to uni rules within the node and 
encounter...
This could lead to a buffer overflow.

(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)

Affects perl >= 5.18 && perl <= 5.26

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/perl/perl/CVE-2018-6797.patch | 45 ++
 meta/recipes-devtools/perl/perl_5.24.1.bb  |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6797.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch
new file mode 100644
index 000..b56ebd3
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch
@@ -0,0 +1,45 @@
+From abe1e6c568b96bcb382dfa4f61c56d1ab001ea51 Mon Sep 17 00:00:00 2001
+From: Karl Williamson 
+Date: Fri, 2 Feb 2018 15:14:27 -0700
+Subject: [PATCH] (perl #132227) restart a node if we change to uni rules
+ within the node and encounter a sharp S
+
+This could lead to a buffer overflow.
+
+(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)
+
+CVE: CVE-2018-6797
+Upstream-Status: Backport 
[https://perl5.git.perl.org/perl.git/commitdiff/abe1e6c568b96bcb382dfa4f61c56d1ab001ea51]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ regcomp.c | 12 
+ 1 file changed, 12 insertions(+)
+
+diff --git a/regcomp.c b/regcomp.c
+index 3b9550b10d..a7dee9a09e 100644
+--- a/regcomp.c
 b/regcomp.c
+@@ -13543,6 +13543,18 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 
*flagp, U32 depth)
+  * /u.  This includes the multi-char fold SHARP S to
+  * 'ss' */
+ if (UNLIKELY(ender == LATIN_SMALL_LETTER_SHARP_S)) {
++
++/* If the node started out having uni rules, we
++ * wouldn't have gotten here.  So this means
++ * something in the middle has changed it, but
++ * didn't think it needed to reparse.  But this
++ * sharp s now does indicate the need for
++ * reparsing. */
++if (RExC_uni_semantics) {
++p = oldp;
++goto loopdone;
++}
++
+ RExC_seen_unfolded_sharp_s = 1;
+ maybe_exactfu = FALSE;
+ }
+-- 
+2.15.1-424-g9478a660812
+
+
diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb 
b/meta/recipes-devtools/perl/perl_5.24.1.bb
index e696910..dafd268 100644
--- a/meta/recipes-devtools/perl/perl_5.24.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
@@ -70,6 +70,7 @@ SRC_URI += " \
 file://CVE-2017-12837.patch \
 file://CVE-2018-6798-1.patch \
 file://CVE-2018-6798-2.patch \
+file://CVE-2018-6797.patch \
 "
 
 # Fix test case issues
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 26/34] shadow: CVE-2018-7169

[Jagadeesh Krishnanjanappa]

newgidmap: enforce setgroups=deny if self-mapping a group

This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.

This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).

We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".

Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
Fixes: CVE-2018-7169

Affects shadow <= 4.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../shadow/files/CVE-2018-7169.patch   | 186 +
 meta/recipes-extended/shadow/shadow.inc|   1 +
 2 files changed, 187 insertions(+)
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2018-7169.patch

diff --git a/meta/recipes-extended/shadow/files/CVE-2018-7169.patch 
b/meta/recipes-extended/shadow/files/CVE-2018-7169.patch
new file mode 100644
index 000..36887d4
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2018-7169.patch
@@ -0,0 +1,186 @@
+From fb28c99b8a66ff2605c5cb96abc0a4d975f92de0 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai 
+Date: Thu, 15 Feb 2018 23:49:40 +1100
+Subject: [PATCH] newgidmap: enforce setgroups=deny if self-mapping a group
+
+This is necessary to match the kernel-side policy of "self-mapping in a
+user namespace is fine, but you cannot drop groups" -- a policy that was
+created in order to stop user namespaces from allowing trivial privilege
+escalation by dropping supplementary groups that were "blacklisted" from
+certain paths.
+
+This is the simplest fix for the underlying issue, and effectively makes
+it so that unless a user has a valid mapping set in /etc/subgid (which
+only administrators can modify) -- and they are currently trying to use
+that mapping -- then /proc/$pid/setgroups will be set to deny. This
+workaround is only partial, because ideally it should be possible to set
+an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
+administrators to further restrict newgidmap(1).
+
+We also don't write anything in the "allow" case because "allow" is the
+default, and users may have already written "deny" even if they
+technically are allowed to use setgroups. And we don't write anything if
+the setgroups policy is already "deny".
+
+Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
+Fixes: CVE-2018-7169
+
+Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/fb28c99b8a66ff2605c5cb96abc0a4d975f92de0]
+Reported-by: Craig Furman 
+Signed-off-by: Aleksa Sarai 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/newgidmap.c | 89 +++--
+ 1 file changed, 80 insertions(+), 9 deletions(-)
+
+diff --git a/src/newgidmap.c b/src/newgidmap.c
+index b1e33513..59a2e75c 100644
+--- a/src/newgidmap.c
 b/src/newgidmap.c
+@@ -46,32 +46,37 @@
+  */
+ const char *Prog;
+ 
+-static bool verify_range(struct passwd *pw, struct map_range *range)
++
++static bool verify_range(struct passwd *pw, struct map_range *range, bool 
*allow_setgroups)
+ {
+   /* An empty range is invalid */
+   if (range->count == 0)
+   return false;
+ 
+-  /* Test /etc/subgid */
+-  if (have_sub_gids(pw->pw_name, range->lower, range->count))
++  /* Test /etc/subgid. If the mapping is valid then we allow setgroups. */
++  if (have_sub_gids(pw->pw_name, range->lower, range->count)) {
++  *allow_setgroups = true;
+   return true;
++  }
+ 
+-  /* Allow a process to map it's own gid */
+-  if ((range->count == 1) && (pw->pw_gid == range->lower))
++  /* Allow a process to map its own gid. */
++  if ((range->count == 1) && (pw->pw_gid == range->lower)) {
++  /* noop -- if setgroups is enabled already we won't disable it. 
*/
+   return true;
++  }
+ 
+   return false;
+ }
+ 
+ static void verify_ranges(struct passwd *pw, int ranges,
+-  struct map_range *mappings)
++  struct map_range *mappings, bool *allow_setgroups)
+ {
+   struct map_range *mapping;
+   int idx;
+ 
+   mapping = mappings;
+   for (idx = 0; idx < ranges; idx++, mapping++) {
+-  if (!verify_range(pw, mapping)) {

[OE-core] [ROCKO][PATCH V3 25/34] qemu: CVE-2018-12617

[Jagadeesh Krishnanjanappa]

qga: check bytes count read by guest-file-read

While reading file content via 'guest-file-read' command,
'qmp_guest_file_read' routine allocates buffer of count+1
bytes. It could overflow for large values of 'count'.
Add check to avoid it.

Affects qemu < v3.0.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2018-12617.patch | 53 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch
new file mode 100644
index 000..c89f189
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch
@@ -0,0 +1,53 @@
+From 141b197408ab398c4f474ac1a728ab316e921f2b Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Wed, 13 Jun 2018 11:46:57 +0530
+Subject: [PATCH] qga: check bytes count read by guest-file-read
+
+While reading file content via 'guest-file-read' command,
+'qmp_guest_file_read' routine allocates buffer of count+1
+bytes. It could overflow for large values of 'count'.
+Add check to avoid it.
+
+Reported-by: Fakhri Zulkifli 
+Signed-off-by: Prasad J Pandit 
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Michael Roth 
+
+CVE: CVE-2018-12617
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=141b197408ab398c4f474ac1a728ab316e921f2b]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ qga/commands-posix.c | 2 +-
+ qga/commands-win32.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/qga/commands-posix.c b/qga/commands-posix.c
+index 594d21ef3e..9284e71666 100644
+--- a/qga/commands-posix.c
 b/qga/commands-posix.c
+@@ -458,7 +458,7 @@ struct GuestFileRead *qmp_guest_file_read(int64_t handle, 
bool has_count,
+ 
+ if (!has_count) {
+ count = QGA_READ_COUNT_DEFAULT;
+-} else if (count < 0) {
++} else if (count < 0 || count >= UINT32_MAX) {
+ error_setg(errp, "value '%" PRId64 "' is invalid for argument count",
+count);
+ return NULL;
+diff --git a/qga/commands-win32.c b/qga/commands-win32.c
+index 70ee5379f6..73f31fa8c2 100644
+--- a/qga/commands-win32.c
 b/qga/commands-win32.c
+@@ -318,7 +318,7 @@ GuestFileRead *qmp_guest_file_read(int64_t handle, bool 
has_count,
+ }
+ if (!has_count) {
+ count = QGA_READ_COUNT_DEFAULT;
+-} else if (count < 0) {
++} else if (count < 0 || count >= UINT32_MAX) {
+ error_setg(errp, "value '%" PRId64
+"' is invalid for argument count", count);
+ return NULL;
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 5b88154..57d5106 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -34,6 +34,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://CVE-2017-15119.patch \
file://CVE-2017-18043.patch \
file://CVE-2018-7550.patch \
+   file://CVE-2018-12617.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 24/34] qemu: CVE-2018-7550

[Jagadeesh Krishnanjanappa]

multiboot: bss_end_addr can be zero

The multiboot spec
(https://www.gnu.org/software/grub/manual/multiboot/),
section 3.1.3, allows for bss_end_addr to be zero.

A zero bss_end_addr signifies there is no .bss section.

Affects qemu < v2.12.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/qemu/qemu/CVE-2018-7550.patch | 62 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch
new file mode 100644
index 000..9923d12
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch
@@ -0,0 +1,62 @@
+From 2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8 Mon Sep 17 00:00:00 2001
+From: Jack Schwartz 
+Date: Thu, 21 Dec 2017 09:25:15 -0800
+Subject: [PATCH] multiboot: bss_end_addr can be zero
+
+The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/),
+section 3.1.3, allows for bss_end_addr to be zero.
+
+A zero bss_end_addr signifies there is no .bss section.
+
+CVE: CVE-2018-7550
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8]
+
+Suggested-by: Daniel Kiper 
+Signed-off-by: Jack Schwartz 
+Reviewed-by: Daniel Kiper 
+Reviewed-by: Prasad J Pandit 
+Signed-off-by: Kevin Wolf 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ hw/i386/multiboot.c | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
+index 46d9c68bf5..bb8d8e4629 100644
+--- a/hw/i386/multiboot.c
 b/hw/i386/multiboot.c
+@@ -233,12 +233,6 @@ int load_multiboot(FWCfgState *fw_cfg,
+ mh_entry_addr = ldl_p(header+i+28);
+ 
+ if (mh_load_end_addr) {
+-if (mh_bss_end_addr < mh_load_addr) {
+-fprintf(stderr, "invalid mh_bss_end_addr address\n");
+-exit(1);
+-}
+-mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+-
+ if (mh_load_end_addr < mh_load_addr) {
+ fprintf(stderr, "invalid mh_load_end_addr address\n");
+ exit(1);
+@@ -249,8 +243,16 @@ int load_multiboot(FWCfgState *fw_cfg,
+ fprintf(stderr, "invalid kernel_file_size\n");
+ exit(1);
+ }
+-mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+-mb_load_size = mb_kernel_size;
++mb_load_size = kernel_file_size - mb_kernel_text_offset;
++}
++if (mh_bss_end_addr) {
++if (mh_bss_end_addr < (mh_load_addr + mb_load_size)) {
++fprintf(stderr, "invalid mh_bss_end_addr address\n");
++exit(1);
++}
++mb_kernel_size = mh_bss_end_addr - mh_load_addr;
++} else {
++mb_kernel_size = mb_load_size;
+ }
+ 
+ /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 48b8675..5b88154 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -33,6 +33,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
file://CVE-2017-15119.patch \
file://CVE-2017-18043.patch \
+   file://CVE-2018-7550.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 23/34] qemu: CVE-2017-18043

[Jagadeesh Krishnanjanappa]

osdep: Fix ROUND_UP(64-bit, 32-bit)

When using bit-wise operations that exploit the power-of-two
nature of the second argument of ROUND_UP(), we still need to
ensure that the mask is as wide as the first argument (done
by using a ternary to force proper arithmetic promotion).
Unpatched, ROUND_UP(2ULL*1024*1024*1024*1024, 512U) produces 0,
instead of the intended 2TiB, because negation of an unsigned
32-bit quantity followed by widening to 64-bits does not
sign-extend the mask.

Broken since its introduction in commit 292c8e50 (v1.5.0).
Callers that passed the same width type to both macro parameters,
or that had other code to ensure the first parameter's maximum
runtime value did not exceed the second parameter's width, are
unaffected, but I did not audit to see which (if any) existing
clients of the macro could trigger incorrect behavior (I found
the bug while adding a new use of the macro).

While preparing the patch, checkpatch complained about poor
spacing, so I also fixed that here and in the nearby DIV_ROUND_UP.

Affects qemu < v2.11.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2017-18043.patch | 63 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch
new file mode 100644
index 000..955a24c
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch
@@ -0,0 +1,63 @@
+From 2098b073f398cd628c09c5a78537a6854e85830d Mon Sep 17 00:00:00 2001
+From: Eric Blake 
+Date: Thu, 14 Sep 2017 08:49:23 -0500
+Subject: [PATCH] osdep: Fix ROUND_UP(64-bit, 32-bit)
+
+When using bit-wise operations that exploit the power-of-two
+nature of the second argument of ROUND_UP(), we still need to
+ensure that the mask is as wide as the first argument (done
+by using a ternary to force proper arithmetic promotion).
+Unpatched, ROUND_UP(2ULL*1024*1024*1024*1024, 512U) produces 0,
+instead of the intended 2TiB, because negation of an unsigned
+32-bit quantity followed by widening to 64-bits does not
+sign-extend the mask.
+
+Broken since its introduction in commit 292c8e50 (v1.5.0).
+Callers that passed the same width type to both macro parameters,
+or that had other code to ensure the first parameter's maximum
+runtime value did not exceed the second parameter's width, are
+unaffected, but I did not audit to see which (if any) existing
+clients of the macro could trigger incorrect behavior (I found
+the bug while adding a new use of the macro).
+
+While preparing the patch, checkpatch complained about poor
+spacing, so I also fixed that here and in the nearby DIV_ROUND_UP.
+
+CVE: CVE-2017-18043
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2098b073f398cd628c09c5a78537a6854]
+
+CC: qemu-triv...@nongnu.org
+CC: qemu-sta...@nongnu.org
+Signed-off-by: Eric Blake 
+Reviewed-by: Laszlo Ersek 
+Reviewed-by: Richard Henderson 
+Signed-off-by: Michael Tokarev 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ include/qemu/osdep.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
+index 72b75bf044..9dd318a7dd 100644
+--- a/include/qemu/osdep.h
 b/include/qemu/osdep.h
+@@ -205,13 +205,13 @@ extern int daemon(int, int);
+ 
+ /* Round number up to multiple. Requires that d be a power of 2 (see
+  * QEMU_ALIGN_UP for a safer but slower version on arbitrary
+- * numbers) */
++ * numbers); works even if d is a smaller type than n.  */
+ #ifndef ROUND_UP
+-#define ROUND_UP(n,d) (((n) + (d) - 1) & -(d))
++#define ROUND_UP(n, d) (((n) + (d) - 1) & -(0 ? (n) : (d)))
+ #endif
+ 
+ #ifndef DIV_ROUND_UP
+-#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
++#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
+ #endif
+ 
+ /*
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index a3cfb7c..48b8675 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -32,6 +32,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://memfd.patch \
file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
file://CVE-2017-15119.patch \
+   file://CVE-2017-18043.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 22/34] libarchive: CVE-2017-14503

[Jagadeesh Krishnanjanappa]

Reject LHA archive entries with negative size.

Affects libarchive = 3.3.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libarchive/libarchive/CVE-2017-14503.patch | 33 ++
 .../libarchive/libarchive_3.3.2.bb |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch

diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
new file mode 100644
index 000..cbce50c
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
@@ -0,0 +1,33 @@
+From 2c8c83b9731ff822fad6cc8c670ea5519c366a14 Mon Sep 17 00:00:00 2001
+From: Joerg Sonnenberger 
+Date: Thu, 19 Jul 2018 21:14:53 +0200
+Subject: [PATCH] Reject LHA archive entries with negative size.
+
+Upstream-Status: Backport 
[https://github.com/libarchive/libarchive/commit/2c8c83b9731ff822fad6cc8c670ea5519c366a14]
+CVE: CVE-2017-14503
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ libarchive/archive_read_support_format_lha.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_lha.c 
b/libarchive/archive_read_support_format_lha.c
+index b8ef4ae1..95c99bb1 100644
+--- a/libarchive/archive_read_support_format_lha.c
 b/libarchive/archive_read_support_format_lha.c
+@@ -701,6 +701,12 @@ archive_read_format_lha_read_header(struct archive_read 
*a,
+* Prepare variables used to read a file content.
+*/
+   lha->entry_bytes_remaining = lha->compsize;
++  if (lha->entry_bytes_remaining < 0) {
++  archive_set_error(>archive,
++  ARCHIVE_ERRNO_FILE_FORMAT,
++  "Invalid LHa entry size");
++  return (ARCHIVE_FATAL);
++  }
+   lha->entry_offset = 0;
+   lha->entry_crc_calculated = 0;
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb 
b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
index 5daca27..3269716 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
@@ -36,6 +36,7 @@ SRC_URI = 
"http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
file://CVE-2017-14166.patch \
file://CVE-2017-14502.patch \
file://non-recursive-extract-and-list.patch \
+   file://CVE-2017-14503.patch \
   "
 
 SRC_URI[md5sum] = "4583bd6b2ebf7e0e8963d90879eb1b27"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 21/34] libsndfile1: CVE-2017-14634

[Jagadeesh Krishnanjanappa]

double64_init: Check psf->sf.channels against upper bound

This prevents division by zero later in the code.

While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.

CVE-2017-14634

Closes: #318

Affects libsndfile1 = 1.0.28

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libsndfile/libsndfile1/CVE-2017-14634.patch| 42 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
new file mode 100644
index 000..39b4ec1
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
@@ -0,0 +1,42 @@
+From 85c877d5072866aadbe8ed0c3e0590fbb5e16788 Mon Sep 17 00:00:00 2001
+From: Fabian Greffrath 
+Date: Thu, 28 Sep 2017 12:15:04 +0200
+Subject: [PATCH] double64_init: Check psf->sf.channels against upper bound
+
+This prevents division by zero later in the code.
+
+While the trivial case to catch this (i.e. sf.channels < 1) has already
+been covered, a crafted file may report a number of channels that is
+so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
+miscalculated to zero (if this makes sense) in the determination of the
+blockwidth. Since we only support a limited number of channels anyway,
+make sure to check here as well.
+
+CVE: CVE-2017-14634
+
+Closes: https://github.com/erikd/libsndfile/issues/318
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/85c877d5072866aadbe8ed0c3e0590fbb5e16788]
+
+Signed-off-by: Erik de Castro Lopo 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/double64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/double64.c b/src/double64.c
+index b318ea8..78dfef7 100644
+--- a/src/double64.c
 b/src/double64.c
+@@ -91,7 +91,7 @@ int
+ double64_init (SF_PRIVATE *psf)
+ { static int double64_caps ;
+ 
+-  if (psf->sf.channels < 1)
++  if (psf->sf.channels < 1 || psf->sf.channels > SF_MAX_CHANNELS)
+   {   psf_log_printf (psf, "double64_init : internal error : channels 
= %d\n", psf->sf.channels) ;
+   return SFE_INTERNAL ;
+   } ;
+-- 
+2.13.3
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index c6f2a46..ed43b74 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2017-8362.patch \
file://CVE-2017-8363.patch \
file://CVE-2017-14245-14246.patch \
+   file://CVE-2017-14634.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 20/34] git: CVE-2017-15298

[Jagadeesh Krishnanjanappa]

revision: quit pruning diff more quickly when possible
When the revision traversal machinery is given a pathspec,
we must compute the parent-diff for each commit to determine
which ones are TREESAME. We set the QUICK diff flag to avoid
looking at more entries than we need; we really just care
whether there are any changes at all.

But there is one case where we want to know a bit more: if
--remove-empty is set, we care about finding cases where the
change consists only of added entries (in which case we may
prune the parent in try_to_simplify_commit()). To cover that
case, our file_add_remove() callback does not quit the diff
upon seeing an added entry; it keeps looking for other types
of entries.

But this means when --remove-empty is not set (and it is not
by default), we compute more of the diff than is necessary.
You can see this in a pathological case where a commit adds
a very large number of entries, and we limit based on a
broad pathspec. E.g.:

  perl -e '
chomp(my $blob = `git hash-object -w --stdin remove_empty_trees. This callback parameter could be
passed to the "add_remove" and "change" callbacks, but
there's not much point. They already receive the
diff_options struct, and doing it this way avoids having to
update the function signature of the other callbacks
(arguably the format_callback and output_prefix functions
could benefit from the same simplification).

Affects git <= 2.14.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../git/files/CVE-2017-15298.patch | 132 +
 meta/recipes-devtools/git/git.inc  |   3 +-
 2 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/files/CVE-2017-15298.patch

diff --git a/meta/recipes-devtools/git/files/CVE-2017-15298.patch 
b/meta/recipes-devtools/git/files/CVE-2017-15298.patch
new file mode 100644
index 000..0d349dd
--- /dev/null
+++ b/meta/recipes-devtools/git/files/CVE-2017-15298.patch
@@ -0,0 +1,132 @@
+From a937b37e766479c8e780b17cce9c4b252fd97e40 Mon Sep 17 00:00:00 2001
+From: Jeff King 
+Date: Fri, 13 Oct 2017 11:27:45 -0400
+Subject: revision: quit pruning diff more quickly when possible
+
+When the revision traversal machinery is given a pathspec,
+we must compute the parent-diff for each commit to determine
+which ones are TREESAME. We set the QUICK diff flag to avoid
+looking at more entries than we need; we really just care
+whether there are any changes at all.
+
+But there is one case where we want to know a bit more: if
+--remove-empty is set, we care about finding cases where the
+change consists only of added entries (in which case we may
+prune the parent in try_to_simplify_commit()). To cover that
+case, our file_add_remove() callback does not quit the diff
+upon seeing an added entry; it keeps looking for other types
+of entries.
+
+But this means when --remove-empty is not set (and it is not
+by default), we compute more of the diff than is necessary.
+You can see this in a pathological case where a commit adds
+a very large number of entries, and we limit based on a
+broad pathspec. E.g.:
+
+  perl -e '
+chomp(my $blob = `git hash-object -w --stdin remove_empty_trees. This callback parameter could be
+passed to the "add_remove" and "change" callbacks, but
+there's not much point. They already receive the
+diff_options struct, and doing it this way avoids having to
+update the function signature of the other callbacks
+(arguably the format_callback and output_prefix functions
+could benefit from the same simplification).
+
+CVE: CVE-2017-15298
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/git/git.git/commit/?id=a937b37e76]
+
+Signed-off-by: Jeff King 
+Signed-off-by: Junio C Hamano 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ diff.h |  1 +
+ revision.c | 16 +---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/diff.h b/diff.h
+index e9ccb38c26..fe5c287a70 100644
+--- a/diff.h
 b/diff.h
+@@ -180,6 +180,7 @@ struct diff_options {
+   pathchange_fn_t pathchange;
+   change_fn_t change;
+   add_remove_fn_t add_remove;
++  void *change_fn_data;
+   diff_format_fn_t format_callback;
+   void *format_callback_data;
+   diff_prefix_fn_t output_prefix;
+diff --git a/revision.c b/revision.c
+index 771d079f6e..7c23ab7afe 100644
+--- a/revision.c
 b/revision.c
+@@ -394,8 +394,16 @@ static struct commit *one_relevant_parent(const struct 
rev_info *revs,
+  * if the whole diff is removal of old data, and otherwise
+  * REV_TREE_DIFFERENT (of course if the trees are the same we
+  * want REV_TREE_SAME).
+- * That means that once we get to REV_TREE_DIFFERENT, we do not
+- * have to look any further.
++ *
++ * The only time we care about the distinction is when
++ * remove_empty_trees is in effect, in which case we care only about
++ * whether the whole change is REV_TREE_NEW, or if there's another type
++ * of change. Which means we can stop the diff 

[OE-core] [ROCKO][PATCH V3 16/34] Qemu: CVE-2018-11806 slirp-heap-buffer-overflow

[Jagadeesh Krishnanjanappa]

From: Jeremy Puhlman 

slirp: correct size computation while concatenating mbuf

While reassembling incoming fragmented datagrams, 'm_cat' routine
extends the 'mbuf' buffer, if it has insufficient room. It computes
a wrong buffer size, which leads to overwriting adjacent heap buffer
area. Correct this size computation in m_cat.

Affects qemu < 3.0.0

Signed-off-by: Jeremy Puhlman 
---
 ...018-11806-QEMU-slirp-heap-buffer-overflow.patch | 71 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch

diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
new file mode 100644
index 000..b3fab26
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
@@ -0,0 +1,71 @@
+From dc21a9d2951f0a2a7e63633e2b5c68c54e4edc4b Mon Sep 17 00:00:00 2001
+From: Jeremy Puhlman 
+Date: Thu, 14 Jun 2018 01:28:49 +
+Subject: [PATCH] QEMU: slirp heap buffer overflow
+
+Subject: [Qemu-devel] [PATCH 1/2] slirp: correct size computation while 
concatenating mbuf
+Date:  Tue, 5 Jun 2018 23:38:35 +0530
+From: Prasad J Pandit 
+
+While reassembling incoming fragmented datagrams, 'm_cat' routine
+extends the 'mbuf' buffer, if it has insufficient room. It computes
+a wrong buffer size, which leads to overwriting adjacent heap buffer
+area. Correct this size computation in m_cat.
+
+Reported-by: ZDI Disclosures 
+Signed-off-by: Prasad J Pandit 
+
+CVE: CVE-2018-11806
+Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/864036e251f54c99d31df124aad7f34f01f5344c#diff-de3b23fd63b9e35d35c454525498d51c]
+
+https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html
+
+---
+ slirp/mbuf.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+Signed-off-by: Jeremy Puhlman 
+---
+ slirp/mbuf.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/slirp/mbuf.c b/slirp/mbuf.c
+index 5ff2455..7fb4501 100644
+--- a/slirp/mbuf.c
 b/slirp/mbuf.c
+@@ -138,7 +138,7 @@ m_cat(struct mbuf *m, struct mbuf *n)
+* If there's no room, realloc
+*/
+   if (M_FREEROOM(m) < n->m_len)
+-  m_inc(m,m->m_size+MINCSIZE);
++   m_inc(m, m->m_len + n->m_len);
+ 
+   memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
+   m->m_len += n->m_len;
+@@ -158,12 +158,12 @@ m_inc(struct mbuf *m, int size)
+ 
+ if (m->m_flags & M_EXT) {
+ datasize = m->m_data - m->m_ext;
+-  m->m_ext = g_realloc(m->m_ext, size);
++  m->m_ext = g_realloc(m->m_ext, size + datasize);
+ m->m_data = m->m_ext + datasize;
+ } else {
+ char *dat;
+ datasize = m->m_data - m->m_dat;
+-  dat = g_malloc(size);
++  dat = g_malloc(size + datasize);
+ memcpy(dat, m->m_dat, m->m_size);
+ 
+ m->m_ext = dat;
+@@ -171,7 +171,7 @@ m_inc(struct mbuf *m, int size)
+ m->m_flags |= M_EXT;
+ }
+ 
+-m->m_size = size;
++m->m_size = size + datasize;
+ 
+ }
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index bdf6c21..89c68f2 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -30,6 +30,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://CVE-2017-14167.patch \
file://ppc_locking.patch \
file://memfd.patch \
+   file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 19/34] openssh: CVE-2017-15906

[Jagadeesh Krishnanjanappa]

disallow creation (of empty files) in read-only mode; reported by
Michal Zalewski, feedback & ok deraadt@

Affects openssh < 7.6

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../openssh/openssh/CVE-2017-15906.patch   | 38 ++
 meta/recipes-connectivity/openssh/openssh_7.5p1.bb |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch

diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch 
b/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch
new file mode 100644
index 000..3ad683d
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch
@@ -0,0 +1,38 @@
+From a6981567e8e215acc1ef690c8dbb30f2d9b00a19 Mon Sep 17 00:00:00 2001
+From: djm 
+Date: Tue, 4 Apr 2017 00:24:56 +
+Subject: [PATCH] disallow creation (of empty files) in read-only mode;
+ reported by Michal Zalewski, feedback & ok deraadt@
+
+CVE: CVE-2017-15906
+Upstream-Status: Backport 
[https://github.com/openbsd/src/commit/a6981567e8e215acc1ef690c8dbb30f2d9b00a19]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ usr.bin/ssh/sftp-server.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/usr.bin/ssh/sftp-server.c b/usr.bin/ssh/sftp-server.c
+index 2510d234a3a..42249ebd60d 100644
+--- a/usr.bin/ssh/sftp-server.c
 b/usr.bin/ssh/sftp-server.c
+@@ -1,4 +1,4 @@
+-/* $OpenBSD: sftp-server.c,v 1.110 2016/09/12 01:22:38 deraadt Exp $ */
++/* $OpenBSD: sftp-server.c,v 1.111 2017/04/04 00:24:56 djm Exp $ */
+ /*
+  * Copyright (c) 2000-2004 Markus Friedl.  All rights reserved.
+  *
+@@ -683,8 +683,8 @@ process_open(u_int32_t id)
+   logit("open \"%s\" flags %s mode 0%o",
+   name, string_from_portable(pflags), mode);
+   if (readonly &&
+-  ((flags & O_ACCMODE) == O_WRONLY ||
+-  (flags & O_ACCMODE) == O_RDWR)) {
++  ((flags & O_ACCMODE) != O_RDONLY ||
++  (flags & (O_CREAT|O_TRUNC)) != 0)) {
+   verbose("Refusing open request in read-only mode");
+   status = SSH2_FX_PERMISSION_DENIED;
+   } else {
+-- 
+2.13.3
+
diff --git a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
index 86ca6ff..395c21b 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
@@ -28,6 +28,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://0001-openssh-Fix-syntax-error-on-x32.patch \
file://sshd_check_keys \
+   file://CVE-2017-15906.patch;striplevel=3 \
"
 
 PAM_SRC_URI = "file://sshd"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 15/34] curl: CVE-2018-0500

[Jagadeesh Krishnanjanappa]

smtp: use the upload buffer size for scratch buffer malloc

... not the read buffer size, as that can be set smaller and thus cause
a buffer overflow! CVE-2018-0500

Reported-by: Peter Wu
Bug: https://curl.haxx.se/docs/adv_2018-70a2.html

Affects curl >= 7.54.1 && curl <= 7.60.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta/recipes-support/curl/curl/CVE-2018-0500.patch | 39 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-0500.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-0500.patch 
b/meta/recipes-support/curl/curl/CVE-2018-0500.patch
new file mode 100644
index 000..4395a3c
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-0500.patch
@@ -0,0 +1,39 @@
+From ba1dbd78e5f1ed67c1b8d37ac89d90e5e330b628 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Wed, 13 Jun 2018 12:24:40 +0200
+Subject: [PATCH] smtp: use the upload buffer size for scratch buffer malloc
+
+... not the read buffer size, as that can be set smaller and thus cause
+a buffer overflow! CVE-2018-0500
+
+Reported-by: Peter Wu
+Bug: https://curl.haxx.se/docs/adv_2018-70a2.html
+
+CVE: CVE-2018-0500
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/ba1dbd78e5f1e.patch]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/smtp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/lib/smtp.c b/lib/smtp.c
+index e6872badb8..ecf10a41ac 100644
+--- a/lib/smtp.c
 b/lib/smtp.c
+@@ -1563,13 +1563,14 @@ CURLcode Curl_smtp_escape_eob(struct connectdata 
*conn, const ssize_t nread)
+   if(!scratch || data->set.crlf) {
+ oldscratch = scratch;
+ 
+-scratch = newscratch = malloc(2 * data->set.buffer_size);
++scratch = newscratch = malloc(2 * UPLOAD_BUFSIZE);
+ if(!newscratch) {
+   failf(data, "Failed to alloc scratch buffer!");
+ 
+   return CURLE_OUT_OF_MEMORY;
+ }
+   }
++  DEBUGASSERT(UPLOAD_BUFSIZE >= nread);
+ 
+   /* Have we already sent part of the EOB? */
+   eob_sent = smtp->eob;
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index 4376bb3..7dc5381 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -9,6 +9,7 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
file://CVE-2018-1000300.patch \
file://CVE-2018-1000301.patch \
+   file://CVE-2018-0500.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 14/34] gnupg: CVE-2018-12020

[Jagadeesh Krishnanjanappa]

gpg: Sanitize diagnostic with the original file name.

* g10/mainproc.c (proc_plaintext): Sanitize verbose output.
--

This fixes a forgotten sanitation of user supplied data in a verbose
mode diagnostic.  The mention CVE is about using this to inject
status-fd lines into the stderr output.  Other harm good as well be
done.  Note that GPGME based applications are not affected because
GPGME does not fold status output into stderr.

CVE-id: CVE-2018-12020
GnuPG-bug-id: 4012

Affects gnupg < 2.2.8

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../gnupg/gnupg/CVE-2018-12020.patch   | 47 ++
 meta/recipes-support/gnupg/gnupg_2.2.0.bb  |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-support/gnupg/gnupg/CVE-2018-12020.patch

diff --git a/meta/recipes-support/gnupg/gnupg/CVE-2018-12020.patch 
b/meta/recipes-support/gnupg/gnupg/CVE-2018-12020.patch
new file mode 100644
index 000..14698db
--- /dev/null
+++ b/meta/recipes-support/gnupg/gnupg/CVE-2018-12020.patch
@@ -0,0 +1,47 @@
+From 13f135c7a252cc46cff96e75968d92b6dc8dce1b Mon Sep 17 00:00:00 2001
+From: Werner Koch 
+Date: Fri, 8 Jun 2018 10:45:21 +0200
+Subject: [PATCH] gpg: Sanitize diagnostic with the original file name.
+
+* g10/mainproc.c (proc_plaintext): Sanitize verbose output.
+--
+
+This fixes a forgotten sanitation of user supplied data in a verbose
+mode diagnostic.  The mention CVE is about using this to inject
+status-fd lines into the stderr output.  Other harm good as well be
+done.  Note that GPGME based applications are not affected because
+GPGME does not fold status output into stderr.
+
+CVE-id: CVE-2018-12020
+GnuPG-bug-id: 4012
+
+Upstream-Status: Backport 
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=13f135c7a252cc46cff96e75968d92b6dc8dce1b]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ g10/mainproc.c | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/g10/mainproc.c b/g10/mainproc.c
+index d2ceec2fd..a9da08f74 100644
+--- a/g10/mainproc.c
 b/g10/mainproc.c
+@@ -851,7 +851,14 @@ proc_plaintext( CTX c, PACKET *pkt )
+   if (pt->namelen == 8 && !memcmp( pt->name, "_CONSOLE", 8))
+ log_info (_("Note: sender requested \"for-your-eyes-only\"\n"));
+   else if (opt.verbose)
+-log_info (_("original file name='%.*s'\n"), pt->namelen, pt->name);
++{
++  /* We don't use print_utf8_buffer because that would require a
++   * string change which we don't want in 2.2.  It is also not
++   * clear whether the filename is always utf-8 encoded.  */
++  char *tmp = make_printable_string (pt->name, pt->namelen, 0);
++  log_info (_("original file name='%.*s'\n"), (int)strlen (tmp), tmp);
++  xfree (tmp);
++}
+ 
+   free_md_filter_context (>mfx);
+   if (gcry_md_open (>mfx.md, 0, 0))
+-- 
+2.13.3
+
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.0.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.0.bb
index 0176ddd..962ae82 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.0.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.0.bb
@@ -14,6 +14,7 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0002-use-pkgconfig-instead-of-npth-config.patch \
file://0003-dirmngr-uses-libgpg-error.patch \
file://0004-autogen.sh-fix-find-version-for-beta-checking.patch \
+   file://CVE-2018-12020.patch \
   "
 
 SRC_URI[md5sum] = "789f16949fae2d003d387f49e9da4b74"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 18/34] pcmanfm: CVE-2017-8934

[Jagadeesh Krishnanjanappa]

Fix potential access violation, use runtime user dir instead of tmp dir.

pcmanfm = 1.2.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-sato/pcmanfm/files/CVE-2017-8934.patch | 60 ++
 meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb |  3 +-
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch

diff --git a/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch 
b/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch
new file mode 100644
index 000..ea34555
--- /dev/null
+++ b/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch
@@ -0,0 +1,60 @@
+From bc8c3d871e9ecc67c47ff002b68cf049793faf08 Mon Sep 17 00:00:00 2001
+From: Andriy Grytsenko 
+Date: Sun, 14 May 2017 21:35:40 +0300
+Subject: [PATCH] Fix potential access violation, use runtime user dir instead
+ of tmp dir.
+
+CVE: CVE-2017-8934
+Upstream-Status: Backport 
[https://git.lxde.org/gitweb/?p=lxde/pcmanfm.git;a=commitdiff;h=bc8c3d871e9ecc67c47ff002b68cf049793faf08]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ NEWS  | 4 
+ src/single-inst.c | 7 ++-
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 8c2049a..876f7f3 100644
+--- a/NEWS
 b/NEWS
+@@ -1,3 +1,7 @@
++* Fixed potential access violation, use runtime user dir instead of tmp dir
++for single instance socket.
++
++
+ Changes on 1.2.5 since 1.2.4:
+ 
+ * Removed options to Cut, Remove and Rename from context menu on mounted
+diff --git a/src/single-inst.c b/src/single-inst.c
+index 62c37b3..aaf84ab 100644
+--- a/src/single-inst.c
 b/src/single-inst.c
+@@ -2,7 +2,7 @@
+  *  single-inst.c: simple IPC mechanism for single instance app
+  *
+  *  Copyright 2010 Hong Jen Yee (PCMan) 
+- *  Copyright 2012 Andriy Grytsenko (LStranger) 
++ *  Copyright 2012-2017 Andriy Grytsenko (LStranger) 
+  *
+  *  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
+@@ -404,11 +404,16 @@ static void get_socket_name(SingleInstData* data, char* 
buf, int len)
+ }
+ else
+ dpynum = 0;
++#if GLIB_CHECK_VERSION(2, 28, 0)
++g_snprintf(buf, len, "%s/%s-socket-%s-%d", g_get_user_runtime_dir(),
++   data->prog_name, host ? host : "", dpynum);
++#else
+ g_snprintf(buf, len, "%s/.%s-socket-%s-%d-%s",
+ g_get_tmp_dir(),
+ data->prog_name,
+ host ? host : "",
+ dpynum,
+ g_get_user_name());
++#endif
+ }
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
index 75ff773..0ab8a2e 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
@@ -17,7 +17,8 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.xz 
\
   file://gnome-fs-regular.png \
   file://gnome-mime-text-plain.png \
   file://emblem-symbolic-link.png \
-  file://no-desktop.patch"
+  file://no-desktop.patch \
+  file://CVE-2017-8934.patch"
 
 SRC_URI[md5sum] = "b4d1f8ce08d87e4f27805a246fc51ac2"
 SRC_URI[sha256sum] = 
"0c86cac028b705ff314c7464d814c2cf7ff604c17491c20aa204b1ef1a80ad67"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 17/34] qemu: CVE-2017-15119

[Jagadeesh Krishnanjanappa]

nbd/server: CVE-2017-15119 Reject options larger than 32M

The NBD spec gives us permission to abruptly disconnect on clients
that send outrageously large option requests, rather than having
to spend the time reading to the end of the option.  No real
option request requires that much data anyways; and meanwhile, we
already have the practice of abruptly dropping the connection on
any client that sends NBD_CMD_WRITE with a payload larger than 32M.

For comparison, nbdkit drops the connection on any request with
more than 4096 bytes; however, that limit is probably too low
(as the NBD spec states an export name can theoretically be up
to 4096 bytes, which means a valid NBD_OPT_INFO could be even
longer) - even if qemu doesn't permit exports longer than 256
bytes.

It could be argued that a malicious client trying to get us to
read nearly 4G of data on a bad request is a form of denial of
service.  In particular, if the server requires TLS, but a client
that does not know the TLS credentials sends any option (other
than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
payload of nearly 4G, then the server was keeping the connection
alive trying to read all the payload, tying up resources that it
would rather be spending on a client that can get past the TLS
handshake.  Hence, this warranted a CVE.

Present since at least 2.5 when handling known options, and made
worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
to handle unknown options.

Affects qemu < 2.11

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2017-15119.patch | 63 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
new file mode 100644
index 000..10da519
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
@@ -0,0 +1,63 @@
+From fdad35ef6c5839d50dfc14073364ac893afebc30 Mon Sep 17 00:00:00 2001
+From: Eric Blake 
+Date: Wed, 22 Nov 2017 16:25:16 -0600
+Subject: [PATCH] nbd/server: CVE-2017-15119 Reject options larger than 32M
+
+The NBD spec gives us permission to abruptly disconnect on clients
+that send outrageously large option requests, rather than having
+to spend the time reading to the end of the option.  No real
+option request requires that much data anyways; and meanwhile, we
+already have the practice of abruptly dropping the connection on
+any client that sends NBD_CMD_WRITE with a payload larger than 32M.
+
+For comparison, nbdkit drops the connection on any request with
+more than 4096 bytes; however, that limit is probably too low
+(as the NBD spec states an export name can theoretically be up
+to 4096 bytes, which means a valid NBD_OPT_INFO could be even
+longer) - even if qemu doesn't permit exports longer than 256
+bytes.
+
+It could be argued that a malicious client trying to get us to
+read nearly 4G of data on a bad request is a form of denial of
+service.  In particular, if the server requires TLS, but a client
+that does not know the TLS credentials sends any option (other
+than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
+payload of nearly 4G, then the server was keeping the connection
+alive trying to read all the payload, tying up resources that it
+would rather be spending on a client that can get past the TLS
+handshake.  Hence, this warranted a CVE.
+
+Present since at least 2.5 when handling known options, and made
+worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
+to handle unknown options.
+
+CC: qemu-sta...@nongnu.org
+CVE: CVE-2017-15119
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commit;h=fdad35ef6c5839d50dfc14073364ac893afebc30]
+
+Signed-off-by: Eric Blake 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ nbd/server.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/nbd/server.c b/nbd/server.c
+index 7d6801b427..a81801e3bc 100644
+--- a/nbd/server.c
 b/nbd/server.c
+@@ -673,6 +673,12 @@ static int nbd_negotiate_options(NBDClient *client, 
uint16_t myflags,
+ }
+ length = be32_to_cpu(length);
+ 
++if (length > NBD_MAX_BUFFER_SIZE) {
++error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u)",
++   length, NBD_MAX_BUFFER_SIZE);
++return -EINVAL;
++}
++
+ trace_nbd_negotiate_options_check_option(option,
+  nbd_opt_lookup(option));
+ if (client->tlscreds &&
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 89c68f2..a3cfb7c 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -31,6 +31,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
  

[OE-core] [ROCKO][PATCH V3 13/34] procps: CVE-2018-1124

[Jagadeesh Krishnanjanappa]

proc/readproc.c: Fix bugs and overflows in file2strvec().

Note: this is by far the most important and complex patch of the whole
series, please review it carefully; thank you very much!

For this patch, we decided to keep the original function's design and
skeleton, to avoid regressions and behavior changes, while fixing the
various bugs and overflows. And like the "Harden file2str()" patch, this
patch does not fail when about to overflow, but truncates instead: there
is information available about this process, so return it to the caller;
also, we used INT_MAX as a limit, but a lower limit could be used.

The easy changes:

- Replace sprintf() with snprintf() (and check for truncation).

- Replace "if (n == 0 && rbuf == 0)" with "if (n <= 0 && tot <= 0)" and
  do break instead of return: it simplifies the code (only one place to
  handle errors), and also guarantees that in the while loop either n or
  tot is > 0 (or both), even if n is reset to 0 when about to overflow.

- Remove the "if (n < 0)" block in the while loop: it is (and was) dead
  code, since we enter the while loop only if n >= 0.

- Rewrite the missing-null-terminator detection: in the original
  function, if the size of the file is a multiple of 2047, a null-
  terminator is appended even if the file is already null-terminated.

- Replace "if (n <= 0 && !end_of_file)" with "if (n < 0 || tot <= 0)":
  originally, it was equivalent to "if (n < 0)", but we added "tot <= 0"
  to handle the first break of the while loop, and to guarantee that in
  the rest of the function tot is > 0.

- Double-force ("belt and suspenders") the null-termination of rbuf:
  this is (and was) essential to the correctness of the function.

- Replace the final "while" loop with a "for" loop that behaves just
  like the preceding "for" loop: in the original function, this would
  lead to unexpected results (for example, if rbuf is |\0|A|\0|, this
  would return the array {"",NULL} but should return {"","A",NULL}; and
  if rbuf is |A|\0|B| (should never happen because rbuf should be null-
  terminated), this would make room for two pointers in ret, but would
  write three pointers to ret).

The hard changes:

- Prevent the integer overflow of tot in the while loop, but unlike
  file2str(), file2strvec() cannot let tot grow until it almost reaches
  INT_MAX, because it needs more space for the pointers: this is why we
  introduced ARG_LEN, which also guarantees that we can add "align" and
  a few sizeof(char*)s to tot without overflowing.

- Prevent the integer overflow of "tot + c + align": when INT_MAX is
  (almost) reached, we write the maximal safe amount of pointers to ret
  (ARG_LEN guarantees that there is always space for *ret = rbuf and the
  NULL terminator).

Affects procps-ng < 3.3.15

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../procps/procps/CVE-2018-1124.patch  | 176 +
 meta/recipes-extended/procps/procps_3.3.12.bb  |   1 +
 2 files changed, 177 insertions(+)
 create mode 100644 meta/recipes-extended/procps/procps/CVE-2018-1124.patch

diff --git a/meta/recipes-extended/procps/procps/CVE-2018-1124.patch 
b/meta/recipes-extended/procps/procps/CVE-2018-1124.patch
new file mode 100644
index 000..bc78faf
--- /dev/null
+++ b/meta/recipes-extended/procps/procps/CVE-2018-1124.patch
@@ -0,0 +1,176 @@
+From bdd058a0e676d2f013027fcfb2b344c313112a50 Mon Sep 17 00:00:00 2001
+From: Qualys Security Advisory 
+Date: Thu, 1 Jan 1970 00:00:00 +
+Subject: [PATCH 074/126] proc/readproc.c: Fix bugs and overflows in
+ file2strvec().
+
+Note: this is by far the most important and complex patch of the whole
+series, please review it carefully; thank you very much!
+
+For this patch, we decided to keep the original function's design and
+skeleton, to avoid regressions and behavior changes, while fixing the
+various bugs and overflows. And like the "Harden file2str()" patch, this
+patch does not fail when about to overflow, but truncates instead: there
+is information available about this process, so return it to the caller;
+also, we used INT_MAX as a limit, but a lower limit could be used.
+
+The easy changes:
+
+- Replace sprintf() with snprintf() (and check for truncation).
+
+- Replace "if (n == 0 && rbuf == 0)" with "if (n <= 0 && tot <= 0)" and
+  do break instead of return: it simplifies the code (only one place to
+  handle errors), and also guarantees that in the while loop either n or
+  tot is > 0 (or both), even if n is reset to 0 when about to overflow.
+
+- Remove the "if (n < 0)" block in the while loop: it is (and was) dead
+  code, since we enter the while loop only if n >= 0.
+
+- Rewrite the missing-null-terminator detection: in the original
+  function, if the size of the file is a multiple of 2047, a null-
+  terminator is appended even if the file is already null-terminated.
+
+- Replace "if (n <= 0 && !end_of_file)" with "if (n < 0 || tot <= 0)":
+  originally, it was equivalent to "if (n < 0)", but we 

[OE-core] [ROCKO][PATCH V3 12/34] curl: CVE-2018-1000301

[Jagadeesh Krishnanjanappa]

http: restore buffer pointer when bad response-line is parsed

... leaving the k->str could lead to buffer over-reads later on.

CVE: CVE-2018-1000301
Assisted-by: Max Dymond

Detected by OSS-Fuzz.
Bug: https://curl.haxx.se/docs/adv_2018-b138.html
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105

Affects curl >= 7.20.0 && curl <= 7.59.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../curl/curl/CVE-2018-1000301.patch   | 54 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-1000301.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-1000301.patch 
b/meta/recipes-support/curl/curl/CVE-2018-1000301.patch
new file mode 100644
index 000..f42178e
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-1000301.patch
@@ -0,0 +1,54 @@
+From 8c7b3737d29ed5c0575bf592063de8a51450812d Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Sat, 24 Mar 2018 23:47:41 +0100
+Subject: [PATCH] http: restore buffer pointer when bad response-line is parsed
+
+... leaving the k->str could lead to buffer over-reads later on.
+
+CVE: CVE-2018-1000301
+Assisted-by: Max Dymond
+
+Detected by OSS-Fuzz.
+Bug: https://curl.haxx.se/docs/adv_2018-b138.html
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105
+
+Upstream-Status: Backport 
[https://github.com/curl/curl-www/commit/3ee30b2b5e3836345ac510bc1674aa3a4272936e]
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/http.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/lib/http.c b/lib/http.c
+index 1a313b4fb..e080ae513 100644
+--- a/lib/http.c
 b/lib/http.c
+@@ -3012,10 +3012,12 @@ CURLcode Curl_http_readwrite_headers(struct Curl_easy 
*data,
+ssize_t *nread,
+bool *stop_reading)
+ {
+   CURLcode result;
+   struct SingleRequest *k = >req;
++  ssize_t onread = *nread;
++  char *ostr = k->str;
+ 
+   /* header line within buffer loop */
+   do {
+ size_t rest_length;
+ size_t full_length;
+@@ -3076,11 +3078,13 @@ CURLcode Curl_http_readwrite_headers(struct Curl_easy 
*data,
+   /* since there's more, this is a partial bad header */
+   k->badheader = HEADER_PARTHEADER;
+ else {
+   /* this was all we read so it's all a bad header */
+   k->badheader = HEADER_ALLBAD;
+-  *nread = (ssize_t)rest_length;
++  *nread = onread;
++  k->str = ostr;
++  return CURLE_OK;
+ }
+ break;
+   }
+ }
+ 
+-- 
+2.17.0
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index fdfbb3d..4376bb3 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
file://CVE-2018-1000300.patch \
+   file://CVE-2018-1000301.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 10/34] perl: CVE-2018-6798

[Jagadeesh Krishnanjanappa]

* CVE-2018-6798-1
 The proximal cause is several instances in regexec.c of the code
 assuming that the input was valid UTF-8, whereas the input was too short
 for what the start byte claimed it would be.

 I grepped through the core for any other similar uses, and did not find
 any.

 (cherry picked from commit fe7d8ba0a1bf567af8fa8fea128e2b9f4c553e84)

* CVE-2018-6798-2
 The first patch for 132063 prevented the buffer read overflow when
 dumping the warning but didn't fix the underlying problem.

 The next change treats the supplied buffer correctly, preventing the
 non-UTF-8 SV from being treated as UTF-8, preventing the warning.

 (cherry picked from commit 1e8b61488f195e1396aa801c685340b156104f4f)

Affects perl >= 5.22 && perl <= 5.26

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../perl/perl/CVE-2018-6798-1.patch| 130 +
 .../perl/perl/CVE-2018-6798-2.patch|  37 ++
 meta/recipes-devtools/perl/perl_5.24.1.bb  |   2 +
 3 files changed, 169 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6798-1.patch
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6798-2.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-6798-1.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-6798-1.patch
new file mode 100644
index 000..3477162
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-6798-1.patch
@@ -0,0 +1,130 @@
+From 0abf1e8d89aecd32dbdabda5da4d52a2d57a7cff Mon Sep 17 00:00:00 2001
+From: Karl Williamson 
+Date: Tue, 6 Feb 2018 14:50:48 -0700
+Subject: [PATCH] [perl #132063]: Heap buffer overflow
+
+The proximal cause is several instances in regexec.c of the code
+assuming that the input was valid UTF-8, whereas the input was too short
+for what the start byte claimed it would be.
+
+I grepped through the core for any other similar uses, and did not find
+any.
+
+(cherry picked from commit fe7d8ba0a1bf567af8fa8fea128e2b9f4c553e84)
+
+CVE: CVE-2018-6798
+Upstream-Status: Backport 
[https://perl5.git.perl.org/perl.git/patch/0abf1e8d89aecd32dbdabda5da4d52a2d57a7cff]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ regexec.c  | 29 -
+ t/lib/warnings/regexec |  7 +++
+ 2 files changed, 23 insertions(+), 13 deletions(-)
+
+diff --git a/regexec.c b/regexec.c
+index 5735b997fd..ea432c39d3 100644
+--- a/regexec.c
 b/regexec.c
+@@ -1466,7 +1466,9 @@ Perl_re_intuit_start(pTHX_
+? trie_utf8_fold   
  \
+:   trie_latin_utf8_fold)))
+ 
+-#define REXEC_TRIE_READ_CHAR(trie_type, trie, widecharmap, uc, uscan, len, 
uvc, charid, foldlen, foldbuf, uniflags) \
++/* 'uscan' is set to foldbuf, and incremented, so below the end of uscan is
++ * 'foldbuf+sizeof(foldbuf)' */
++#define REXEC_TRIE_READ_CHAR(trie_type, trie, widecharmap, uc, uc_end, uscan, 
len, uvc, charid, foldlen, foldbuf, uniflags) \
+ STMT_START {  
  \
+ STRLEN skiplen;   
  \
+ U8 flags = FOLD_FLAGS_FULL;   
  \
+@@ -1474,7 +1476,7 @@ STMT_START {
+ case trie_flu8:   
  \
+ _CHECK_AND_WARN_PROBLEMATIC_LOCALE;   
  \
+ if (utf8_target && UTF8_IS_ABOVE_LATIN1(*uc)) {   
  \
+-_CHECK_AND_OUTPUT_WIDE_LOCALE_UTF8_MSG(uc, uc + UTF8SKIP(uc));
  \
++_CHECK_AND_OUTPUT_WIDE_LOCALE_UTF8_MSG(uc, uc_end - uc);  
  \
+ } 
  \
+ goto do_trie_utf8_fold;   
  \
+ case trie_utf8_exactfa_fold:  
  \
+@@ -1483,7 +1485,7 @@ STMT_START {
+ case trie_utf8_fold:  
  \
+   do_trie_utf8_fold:  
  \
+ if ( foldlen>0 ) {
  \
+-uvc = utf8n_to_uvchr( (const U8*) uscan, UTF8_MAXLEN, , 
uniflags ); \
++uvc = utf8n_to_uvchr( (const U8*) uscan, foldlen, , uniflags 
); \
+ foldlen -= len;   
  \
+ uscan += len; 
  \
+ len=0;
  \
+@@ -1500,7 +1502,7 @@ STMT_START {
+ /* FALLTHROUGH */ 
  \
+ case trie_latin_utf8_fold:
  \
+ if ( foldlen>0 ) {

[OE-core] [ROCKO][PATCH V3 11/34] curl: CVE-2018-1000300

[Jagadeesh Krishnanjanappa]

pingpong: fix response cache memcpy overflow

Response data for a handle with a large buffer might be cached and then
used with the "closure" handle when it has a smaller buffer and then
he
larger cache will be copied and overflow the new smaller heap based
buffer.

Reported-by: Dario Weisser
CVE: CVE-2018-1000300
Bug: https://curl.haxx.se/docs/adv_2018-82c2.html

Affects curl >= 7.54.1 && curl <= 7.59.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../curl/curl/CVE-2018-1000300.patch   | 44 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-1000300.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-1000300.patch 
b/meta/recipes-support/curl/curl/CVE-2018-1000300.patch
new file mode 100644
index 000..893d45c
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-1000300.patch
@@ -0,0 +1,44 @@
+From 0a79d714bd55779a3a223efb5c089d0ad7e128a8 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Fri, 23 Mar 2018 23:30:04 +0100
+Subject: [PATCH] pingpong: fix response cache memcpy overflow
+
+Response data for a handle with a large buffer might be cached and then
+used with the "closure" handle when it has a smaller buffer and then the
+larger cache will be copied and overflow the new smaller heap based
+buffer.
+
+Reported-by: Dario Weisser
+
+CVE: CVE-2018-1000300
+Bug: https://curl.haxx.se/docs/adv_2018-82c2.html
+Upstream-Status: Backport 
[https://github.com/curl/curl-www/commit/3ee30b2b5e3836345ac510bc1674aa3a4272936e]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/pingpong.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/lib/pingpong.c b/lib/pingpong.c
+index 438856a99..ad370ee82 100644
+--- a/lib/pingpong.c
 b/lib/pingpong.c
+@@ -302,11 +302,14 @@ CURLcode Curl_pp_readresp(curl_socket_t sockfd,
+*
+* pp->cache_size is cast to ssize_t here.  This should be safe, because
+* it would have been populated with something of size int to begin
+* with, even though its datatype may be larger than an int.
+*/
+-  DEBUGASSERT((ptr + pp->cache_size) <= (buf + data->set.buffer_size + 
1));
++  if((ptr + pp->cache_size) > (buf + data->set.buffer_size + 1)) {
++failf(data, "cached response data too big to handle");
++return CURLE_RECV_ERROR;
++  }
+   memcpy(ptr, pp->cache, pp->cache_size);
+   gotbytes = (ssize_t)pp->cache_size;
+   free(pp->cache);/* free the cache */
+   pp->cache = NULL;   /* clear the pointer */
+   pp->cache_size = 0; /* zero the size just in case */
+-- 
+2.17.0
+
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index d2d0180..fdfbb3d 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
+   file://CVE-2018-1000300.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 08/34] util-linux: CVE-2018-7738

[Jagadeesh Krishnanjanappa]

bash-completion: (umount) use findmnt, escape a space in paths

 # mount /dev/sdc1 /mnt/test/foo\ bar
 # umount 

has to return "/mnt/test/foo\ bar".

Changes:

 * don't use mount | awk output, we have findmnt
 * force compgen use \n as entries separator

Affects util-linux < 2.32-rc1

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../util-linux/util-linux/CVE-2018-7738.patch  | 49 ++
 meta/recipes-core/util-linux/util-linux_2.30.bb|  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 meta/recipes-core/util-linux/util-linux/CVE-2018-7738.patch

diff --git a/meta/recipes-core/util-linux/util-linux/CVE-2018-7738.patch 
b/meta/recipes-core/util-linux/util-linux/CVE-2018-7738.patch
new file mode 100644
index 000..7322b9c
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux/CVE-2018-7738.patch
@@ -0,0 +1,49 @@
+From 75f03badd7ed9f1dd951863d75e756883d3acc55 Mon Sep 17 00:00:00 2001
+From: Karel Zak 
+Date: Thu, 16 Nov 2017 16:27:32 +0100
+Subject: [PATCH] bash-completion: (umount) use findmnt, escape a space in
+ paths
+
+ # mount /dev/sdc1 /mnt/test/foo\ bar
+ # umount 
+
+has to return "/mnt/test/foo\ bar".
+
+Changes:
+
+ * don't use mount | awk output, we have findmnt
+ * force compgen use \n as entries separator
+
+Addresses: https://github.com/karelzak/util-linux/issues/539
+Signed-off-by: Karel Zak 
+
+CVE: CVE-2018-7738
+Upstream-Status: Backport 
[https://github.com/karelzak/util-linux/commit/75f03badd7ed9f1dd951863d75e756883d3acc55]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ bash-completion/umount | 9 +
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/bash-completion/umount b/bash-completion/umount
+index d76cb9fff..98c90d61a 100644
+--- a/bash-completion/umount
 b/bash-completion/umount
+@@ -40,9 +40,10 @@ _umount_module()
+   return 0
+   ;;
+   esac
+-  local DEVS_MPOINTS
+-  DEVS_MPOINTS="$(mount | awk '{print $1, $3}')"
+-  COMPREPLY=( $(compgen -W "$DEVS_MPOINTS" -- $cur) )
+-  return 0
++
++  local oldifs=$IFS
++  IFS=$'\n'
++  COMPREPLY=( $( compgen -W '$(findmnt -lno TARGET | sed 
"s/\([[:blank:]]\)/\1/g")' -- "$cur" ) )
++  IFS=$oldifs
+ }
+ complete -F _umount_module umount
+-- 
+2.13.3
+
diff --git a/meta/recipes-core/util-linux/util-linux_2.30.bb 
b/meta/recipes-core/util-linux/util-linux_2.30.bb
index 6b309b5..a6d23d8 100644
--- a/meta/recipes-core/util-linux/util-linux_2.30.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.30.bb
@@ -14,6 +14,7 @@ SRC_URI += "file://configure-sbindir.patch \
 file://run-ptest \
 file://display_testname_for_subtest.patch \
 file://avoid_parallel_tests.patch \
+file://CVE-2018-7738.patch \
 "
 SRC_URI[md5sum] = "eaa3429150268027908a1b8ae6ee9a62"
 SRC_URI[sha256sum] = 
"c208a4ff6906cb7f57940aa5bc3a6eed146e50a7cc0a092f52ef2ab65057a08d"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 09/34] python: CVE-2018-1000030

[Jagadeesh Krishnanjanappa]

* CVE-2018-130-1
[2.7] bpo-31530: Stop crashes when iterating over a file on multiple threads

* CVE-2018-130-2
Multiple threads iterating over a file can corrupt the file's internal readahead
buffer resulting in crashes. To fix this, cache buffer state thread-locally for
the duration of a file_iternext call and only update the file's internal state
after reading completes.

No attempt is made to define or provide "reasonable" semantics for iterating
over a file on multiple threads. (Non-crashing) races are still
present. Duplicated, corrupt, and missing data will happen.

This was originally fixed by 6401e56, which
raised an exception from seek() and next() when concurrent operations were
detected. Alas, this simpler solution breaks legitimate use cases such as
capturing the standard streams when multiple threads are logging.

Affects python <= 2.7.17

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta/recipes-devtools/python/python.inc|   5 +-
 .../python/python/CVE-2018-130-1.patch | 138 ++
 .../python/python/CVE-2018-130-2.patch | 306 +
 3 files changed, 448 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/python/python/CVE-2018-130-1.patch
 create mode 100644 meta/recipes-devtools/python/python/CVE-2018-130-2.patch

diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index b40f551..03ae5de 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -7,7 +7,10 @@ INC_PR = "r1"
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=6b60258130e4ed10d3101517eb5b9385"
 
-SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz;
+PR .= ".1"
+SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
+   file://CVE-2018-130-1.patch \
+   file://CVE-2018-130-2.patch"
 
 SRC_URI[md5sum] = "53b43534153bb2a0363f08bae8b9d990"
 SRC_URI[sha256sum] = 
"35d543986882f78261f97787fd3e06274bfa6df29fac9b4a94f73930ff98f731"
diff --git a/meta/recipes-devtools/python/python/CVE-2018-130-1.patch 
b/meta/recipes-devtools/python/python/CVE-2018-130-1.patch
new file mode 100644
index 000..c2933cf
--- /dev/null
+++ b/meta/recipes-devtools/python/python/CVE-2018-130-1.patch
@@ -0,0 +1,138 @@
+From 6401e5671781eb217ee1afb4603cc0d1b0367ae6 Mon Sep 17 00:00:00 2001
+From: Serhiy Storchaka 
+Date: Fri, 10 Nov 2017 12:58:55 +0200
+Subject: [PATCH] [2.7] bpo-31530: Stop crashes when iterating over a file on
+ multiple threads. (#3672)
+
+CVE: CVE-2018-130
+Upstream-Status: Backport 
[https://github.com/python/cpython/commit/6401e5671781eb217ee1afb4603cc0d1b0367ae6]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ Lib/test/test_file2k.py| 32 ++
+ .../2017-09-20-18-28-09.bpo-31530.CdLOM7.rst   |  4 +++
+ Objects/fileobject.c   | 19 +++--
+ 3 files changed, 52 insertions(+), 3 deletions(-)
+ create mode 100644 Misc/NEWS.d/next/Core and 
Builtins/2017-09-20-18-28-09.bpo-31530.CdLOM7.rst
+
+diff --git a/Lib/test/test_file2k.py b/Lib/test/test_file2k.py
+index e39ef7042e..d8966e034e 100644
+--- a/Lib/test/test_file2k.py
 b/Lib/test/test_file2k.py
+@@ -652,6 +652,38 @@ class FileThreadingTests(unittest.TestCase):
+ self.f.writelines('')
+ self._test_close_open_io(io_func)
+ 
++def test_iteration_torture(self):
++# bpo-31530: Crash when concurrently iterate over a file.
++with open(self.filename, "wb") as fp:
++for i in xrange(2**20):
++fp.write(b"0"*50 + b"\n")
++with open(self.filename, "rb") as f:
++def iterate():
++try:
++for l in f:
++pass
++except IOError:
++pass
++self._run_workers(iterate, 10)
++
++def test_iteration_seek(self):
++# bpo-31530: Crash when concurrently seek and iterate over a file.
++with open(self.filename, "wb") as fp:
++for i in xrange(1):
++fp.write(b"0"*50 + b"\n")
++with open(self.filename, "rb") as f:
++it = iter([1] + [0]*10)  # one thread reads, others seek
++def iterate():
++try:
++if next(it):
++for l in f:
++pass
++else:
++for i in range(100):
++f.seek(i*100, 0)
++except IOError:
++pass
++self._run_workers(iterate, 10)
+ 
+ @unittest.skipUnless(os.name == 'posix', 'test requires a posix system.')
+ class TestFileSignalEINTR(unittest.TestCase):
+diff --git a/Misc/NEWS.d/next/Core and 
Builtins/2017-09-20-18-28-09.bpo-31530.CdLOM7.rst b/Misc/NEWS.d/next/Core and 

[OE-core] [ROCKO][PATCH V3 06/34] coreutils: CVE-2017-18018

[Jagadeesh Krishnanjanappa]

CVE-2017-18018-1:
doc: clarify chown/chgrp --dereference defaults
* doc/coreutils.texi: the documentation for the --dereference
  flag of chown/chgrp states that it is the default mode of
  operation. Document that this is only the case when operating
  non-recursively.

CVE-2017-18018-2:
doc: warn about following symlinks recursively in chown/chgrp
In both chown and chgrp (which shares its code with chown), operating
on symlinks recursively has a window of vulnerability where the
destination user or group can change the target of the operation.
Warn about combining the --dereference, --recursive, and -L flags.

* doc/coreutils.texi (warnOptDerefWithRec): Add macro.
(node chown invocation): Add it to --dereference and -L.
(node chgrp invocation): Likewise.

Affects coreutils <= 8.29

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../coreutils/coreutils/CVE-2017-18018-1.patch | 40 +++
 .../coreutils/coreutils/CVE-2017-18018-2.patch | 83 ++
 meta/recipes-core/coreutils/coreutils_8.27.bb  |  2 +
 3 files changed, 125 insertions(+)
 create mode 100644 meta/recipes-core/coreutils/coreutils/CVE-2017-18018-1.patch
 create mode 100644 meta/recipes-core/coreutils/coreutils/CVE-2017-18018-2.patch

diff --git a/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-1.patch 
b/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-1.patch
new file mode 100644
index 000..6f31eba
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-1.patch
@@ -0,0 +1,40 @@
+From 7597cfa482e42a00a69fb9577ee523762980a9a2 Mon Sep 17 00:00:00 2001
+From: Michael Orlitzky 
+Date: Thu, 28 Dec 2017 15:52:42 -0500
+Subject: doc: clarify chown/chgrp --dereference defaults
+
+* doc/coreutils.texi: the documentation for the --dereference
+  flag of chown/chgrp states that it is the default mode of
+  operation. Document that this is only the case when operating
+  non-recursively.
+
+CVE: CVE-2017-18018
+Upstream-Status: Backport from v8.30
+
+Signed-off-by: Michael Orlitzky 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ doc/coreutils.texi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff -Naurp coreutils-8.27_org/doc/coreutils.texi 
coreutils-8.27/doc/coreutils.texi
+--- coreutils-8.27_org/doc/coreutils.texi  2018-07-22 21:09:50.128736692 
-0700
 coreutils-8.27/doc/coreutils.texi  2018-07-22 21:12:59.972219770 -0700
+@@ -10952,7 +10952,7 @@ chown -h -R --from=OLDUSER NEWUSER /
+ @cindex symbolic links, changing owner
+ @findex lchown
+ Do not act on symbolic links themselves but rather on what they point to.
+-This is the default.
++This is the default when not operating recursively.
+ 
+ @item -h
+ @itemx --no-dereference
+@@ -11082,7 +11082,7 @@ changed.
+ @cindex symbolic links, changing owner
+ @findex lchown
+ Do not act on symbolic links themselves but rather on what they point to.
+-This is the default.
++This is the default when not operating recursively.
+ 
+ @item -h
+ @itemx --no-dereference
diff --git a/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-2.patch 
b/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-2.patch
new file mode 100644
index 000..c8f5f54
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/CVE-2017-18018-2.patch
@@ -0,0 +1,83 @@
+From bc2fd9796403e03bb757b064d44c22fab92e6842 Mon Sep 17 00:00:00 2001
+From: Michael Orlitzky 
+Date: Thu, 4 Jan 2018 11:38:21 -0500
+Subject: doc: warn about following symlinks recursively in chown/chgrp
+
+In both chown and chgrp (which shares its code with chown), operating
+on symlinks recursively has a window of vulnerability where the
+destination user or group can change the target of the operation.
+Warn about combining the --dereference, --recursive, and -L flags.
+
+* doc/coreutils.texi (warnOptDerefWithRec): Add macro.
+(node chown invocation): Add it to --dereference and -L.
+(node chgrp invocation): Likewise.
+
+See also: CVE-2017-18018
+CVE: CVE-2017-18018
+Upstream-Status: Backport from v8.30
+
+Signed-off-by: Michael Orlitzky 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ doc/coreutils.texi | 17 +
+ 1 file changed, 17 insertions(+)
+
+diff --git a/doc/coreutils.texi b/doc/coreutils.texi
+index 6bb9f09..9f5f95b 100644
+--- a/doc/coreutils.texi
 b/doc/coreutils.texi
+@@ -1428,6 +1428,19 @@ a command line argument is a symbolic link to a 
directory, traverse it.
+ In a recursive traversal, traverse every symbolic link to a directory
+ that is encountered.
+ @end macro
++
++@c Append the following warning to -L where appropriate (e.g. chown).
++@macro warnOptDerefWithRec
++
++Combining this dereferencing option with the @option{--recursive} option
++may create a security risk:
++During the traversal of the directory tree, an attacker may be able to
++introduce a symlink to an arbitrary target; when the tool reaches that,
++the operation will be performed on the target of that symlink,
++possibly allowing the attacker to escalate privileges.
++

[OE-core] [ROCKO][PATCH V3 07/34] gdk-pixbuf: CVE-2017-1000422

[Jagadeesh Krishnanjanappa]

io-gif: Fail quickly when image dimensions are too big

Fail quickly when the dimensions would create an image that's bigger
than MAXINT bytes long.

See https://bugzilla.gnome.org/show_bug.cgi?id=765094

https://bugzilla.gnome.org/show_bug.cgi?id=785973

Affects gdk-pixbuf <= 2.36.8

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../gdk-pixbuf/gdk-pixbuf/CVE-2017-1000422.patch   | 65 ++
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.8.bb |  1 +
 2 files changed, 66 insertions(+)
 create mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/CVE-2017-1000422.patch

diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/CVE-2017-1000422.patch 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/CVE-2017-1000422.patch
new file mode 100644
index 000..0638c99
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/CVE-2017-1000422.patch
@@ -0,0 +1,65 @@
+From 0012e066ba37439d402ce46afbc1311530a4ec61 Mon Sep 17 00:00:00 2001
+From: Bastien Nocera 
+Date: Wed, 23 Aug 2017 18:02:41 +0200
+Subject: [PATCH] io-gif: Fail quickly when image dimensions are too big
+
+Fail quickly when the dimensions would create an image that's bigger
+than MAXINT bytes long.
+
+See https://bugzilla.gnome.org/show_bug.cgi?id=765094
+
+https://bugzilla.gnome.org/show_bug.cgi?id=785973
+
+CVE: CVE-2017-1000422
+Upstream-Status: Backport 
[https://gitlab.gnome.org/GNOME/gdk-pixbuf/commit/0012e06]
+
+Signed-off-by: Bastien Nocera 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ gdk-pixbuf/io-gif.c | 30 +++---
+ 1 file changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/gdk-pixbuf/io-gif.c b/gdk-pixbuf/io-gif.c
+index 057960c..ef10017 100644
+--- a/gdk-pixbuf/io-gif.c
 b/gdk-pixbuf/io-gif.c
+@@ -851,13 +851,29 @@ gif_get_lzw (GifContext *context)
+ pixels[2] = 0;
+ pixels[3] = 0;
+ }
+-} else
+-context->frame->pixbuf =
+-gdk_pixbuf_new (GDK_COLORSPACE_RGB,
+-TRUE,
+-8,
+-context->frame_len,
+-context->frame_height);
++} else {
++int rowstride;
++guint64 len;
++
++rowstride = gdk_pixbuf_calculate_rowstride 
(GDK_COLORSPACE_RGB,
++TRUE,
++8,
++
context->frame_len,
++
context->frame_height);
++if (rowstride > 0 &&
++g_uint64_checked_mul (, rowstride, 
context->frame_height) &&
++len <= G_MAXINT) {
++context->frame->pixbuf =
++gdk_pixbuf_new (GDK_COLORSPACE_RGB,
++TRUE,
++8,
++context->frame_len,
++
context->frame_height);
++} else {
++context->frame->pixbuf = NULL;
++}
++}
++
+ if (!context->frame->pixbuf) {
+ g_free (context->frame);
+ g_set_error_literal (context->error,
+-- 
+2.7.4
+
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.8.bb 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.8.bb
index 8c35904..cf06a85 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.8.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.8.bb
@@ -19,6 +19,7 @@ SRC_URI = 
"${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
file://fatal-loader.patch \
file://0001-Work-around-thumbnailer-cross-compile-failure.patch \
file://0001-queryloaders-Make-output-more-reproducible.patch \
+   file://CVE-2017-1000422.patch \
"
 
 SRC_URI[md5sum] = "e0aaa0061eb12667b32b27472230b962"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 04/34] libvorbis: CVE-2017-14160

[Jagadeesh Krishnanjanappa]

CVE-2017-14160: fix bounds check on very low sample rates.

Affects libvorbis = 1.3.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libvorbis/libvorbis/CVE-2017-14160.patch   | 33 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  2 ++
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14160.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14160.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14160.patch
new file mode 100644
index 000..5f304aa
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14160.patch
@@ -0,0 +1,33 @@
+From 018ca26dece618457dd13585cad52941193c4a25 Mon Sep 17 00:00:00 2001
+From: Thomas Daede 
+Date: Wed, 9 May 2018 14:56:59 -0700
+Subject: [PATCH] CVE-2017-14160: fix bounds check on very low sample rates.
+
+CVE: CVE-2017-14160
+CVE: CVE-2018-10393
+Upstream-Status: Backport 
[https://gitlab.xiph.org/xiph/vorbis/commit/018ca26dece618457dd13585cad52941193c4a25]
+
+Signed-off-by: Thomas Daede 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/psy.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/lib/psy.c b/lib/psy.c
+index 422c6f1..1310123 100644
+--- a/lib/psy.c
 b/lib/psy.c
+@@ -602,8 +602,9 @@ static void bark_noise_hybridmp(int n,const long *b,
+   for (i = 0, x = 0.f;; i++, x += 1.f) {
+ 
+ lo = b[i] >> 16;
+-if( lo>=0 ) break;
+ hi = b[i] & 0x;
++if( lo>=0 ) break;
++if( hi>=n ) break;
+ 
+ tN = N[hi] + N[-lo];
+ tX = X[hi] - X[-lo];
+-- 
+2.7.4
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 20f887c..1a49e59 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -9,12 +9,14 @@ LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=7d2c487d2fc7dd3e3c7c465a5b7f6217 \
 
file://include/vorbis/vorbisenc.h;beginline=1;endline=11;md5=d1c1d138863d6315131193d4046d81cb"
 DEPENDS = "libogg"
+PR = "r1"
 
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
file://CVE-2017-14633.patch \
file://CVE-2017-14632.patch \
file://CVE-2018-5146.patch \
+   file://CVE-2017-14160.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 05/34] rpm: CVE-2017-7501

[Jagadeesh Krishnanjanappa]

Open newly created files with O_EXCL to prevent symlink tricks.
When reopening hardlinks for writing the actual content, use append
mode instead. This is compatible with the write-only permissions but
is not destructive in case we got redirected to somebody elses file,
verify the target before actually writing anything.

As these are files with the temporary suffix, errors mean a local
user with sufficient privileges to break the installation of the package
anyway is trying to goof us on purpose, don't bother trying to mend it
(we couldn't fix the hardlink case anyhow) but just bail out.

Based on a patch by Florian Festi.

Affects rpm < 4.13.0.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/rpm/files/CVE-2017-7501.patch | 106 +
 meta/recipes-devtools/rpm/rpm_git.bb   |   1 +
 2 files changed, 107 insertions(+)
 create mode 100644 meta/recipes-devtools/rpm/files/CVE-2017-7501.patch

diff --git a/meta/recipes-devtools/rpm/files/CVE-2017-7501.patch 
b/meta/recipes-devtools/rpm/files/CVE-2017-7501.patch
new file mode 100644
index 000..fb299d9
--- /dev/null
+++ b/meta/recipes-devtools/rpm/files/CVE-2017-7501.patch
@@ -0,0 +1,106 @@
+From 404ef011c300207cdb1e531670384564aae04bdc Mon Sep 17 00:00:00 2001
+From: Panu Matilainen 
+Date: Tue, 19 Sep 2017 14:46:36 +0300
+Subject: [PATCH] Don't follow symlinks on file creation (CVE-2017-7501)
+
+Open newly created files with O_EXCL to prevent symlink tricks.
+When reopening hardlinks for writing the actual content, use append
+mode instead. This is compatible with the write-only permissions but
+is not destructive in case we got redirected to somebody elses file,
+verify the target before actually writing anything.
+
+As these are files with the temporary suffix, errors mean a local
+user with sufficient privileges to break the installation of the package
+anyway is trying to goof us on purpose, don't bother trying to mend it
+(we couldn't fix the hardlink case anyhow) but just bail out.
+
+Based on a patch by Florian Festi.
+
+CVE: CVE-2017-7501
+Upstream-Status: Backport 
[https://github.com/rpm-software-management/rpm/commit/404ef011c300207cdb1e531670384564aae04bdc]
+
+Signed-off-by: Panu Matilainen 
+Signed-off-by: Florian Festi 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/fsm.c | 29 +++--
+ 1 file changed, 23 insertions(+), 6 deletions(-)
+
+diff --git a/lib/fsm.c b/lib/fsm.c
+index 553774b..e0e9d03 100644
+--- a/lib/fsm.c
 b/lib/fsm.c
+@@ -206,11 +206,22 @@ static int fsmSetFCaps(const char *path, const char 
*captxt)
+ return rc;
+ }
+ 
++/* Check dest is the same, empty and regular file with writeonly permissions 
*/
++static int linkSane(FD_t wfd, const char *dest)
++{
++struct stat sb, lsb;
++
++return (fstat(Fileno(wfd), ) == 0 && sb.st_size == 0 &&
++  (sb.st_mode & ~S_IFMT) == S_IWUSR &&
++  lstat(dest, ) == 0 && S_ISREG(lsb.st_mode) &&
++  sb.st_dev == lsb.st_dev && sb.st_ino == lsb.st_ino);
++}
++
+ /** \ingroup payload
+  * Create file from payload stream.
+  * @return0 on success
+  */
+-static int expandRegular(rpmfi fi, const char *dest, rpmpsm psm, int 
nodigest, int nocontent)
++static int expandRegular(rpmfi fi, const char *dest, rpmpsm psm, int 
exclusive, int nodigest, int nocontent)
+ {
+ FD_t wfd = NULL;
+ int rc = 0;
+@@ -218,8 +229,14 @@ static int expandRegular(rpmfi fi, const char *dest, 
rpmpsm psm, int nodigest, i
+ /* Create the file with 0200 permissions (write by owner). */
+ {
+   mode_t old_umask = umask(0577);
+-  wfd = Fopen(dest, "w.ufdio");
++  wfd = Fopen(dest, exclusive ? "wx.ufdio" : "a.ufdio");
+   umask(old_umask);
++
++  /* If reopening, make sure the file is what we expect */
++  if (!exclusive && wfd != NULL && !linkSane(wfd, dest)) {
++  rc = RPMERR_OPEN_FAILED;
++  goto exit;
++  }
+ }
+ if (Ferror(wfd)) {
+   rc = RPMERR_OPEN_FAILED;
+@@ -248,7 +265,7 @@ static int fsmMkfile(rpmfi fi, const char *dest, rpmfiles 
files,
+   /* Create first hardlinked file empty */
+   if (*firsthardlink < 0) {
+   *firsthardlink = rpmfiFX(fi);
+-  rc = expandRegular(fi, dest, psm, nodigest, 1);
++  rc = expandRegular(fi, dest, psm, 1, nodigest, 1);
+   } else {
+   /* Create hard links for others */
+   char *fn = rpmfilesFN(files, *firsthardlink);
+@@ -263,10 +280,10 @@ static int fsmMkfile(rpmfi fi, const char *dest, 
rpmfiles files,
+existing) file with content */
+ if (numHardlinks<=1) {
+   if (!rc)
+-  rc = expandRegular(fi, dest, psm, nodigest, 0);
++  rc = expandRegular(fi, dest, psm, 1, nodigest, 0);
+ } else if (rpmfiArchiveHasContent(fi)) {
+   if (!rc)
+-  rc = expandRegular(fi, dest, psm, nodigest, 0);
++  rc = expandRegular(fi, dest, psm, 0, nodigest, 0);
+   *firsthardlink = -1;
+ } else {
+ 

[OE-core] [ROCKO][PATCH V3 03/34] libsndfile1: CVE-2017-14245 CVE-2017-14246

[Jagadeesh Krishnanjanappa]

sfe_copy_data_fp: check value of "max" variable for being normal
and check elements of the data[] array for being finite.

Both checks use functions provided by the  header as declared
by the C99 standard.

Fixes #317
CVE-2017-14245
CVE-2017-14246

Affects libsndfile1 = 1.0.28

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libsndfile1/CVE-2017-14245-14246.patch | 121 +
 .../libsndfile/libsndfile1_1.0.28.bb   |   1 +
 2 files changed, 122 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
new file mode 100644
index 000..07c7d13
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
@@ -0,0 +1,121 @@
+From 2d54514a4f6437b67829717c05472d2e3300a258 Mon Sep 17 00:00:00 2001
+From: Fabian Greffrath 
+Date: Wed, 27 Sep 2017 14:46:17 +0200
+Subject: [PATCH] sfe_copy_data_fp: check value of "max" variable for being
+ normal
+
+and check elements of the data[] array for being finite.
+
+Both checks use functions provided by the  header as declared
+by the C99 standard.
+
+Fixes #317
+CVE: CVE-2017-14245
+CVE: CVE-2017-14246
+
+Upstream-Status: Backport 
[https://github.com/fabiangreffrath/libsndfile/commit/2d54514a4f6437b67829717c05472d2e3300a258]
+
+Signed-off-by: Fabian Greffrath 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ programs/common.c  | 20 
+ programs/common.h  |  2 +-
+ programs/sndfile-convert.c |  6 +-
+ 3 files changed, 22 insertions(+), 6 deletions(-)
+
+diff --git a/programs/common.c b/programs/common.c
+index a21e62c..a249a58 100644
+--- a/programs/common.c
 b/programs/common.c
+@@ -36,6 +36,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ 
+@@ -45,7 +46,7 @@
+ 
+ #define   MIN(x, y)   ((x) < (y) ? (x) : (y))
+ 
+-void
++int
+ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize)
+ { static double   data [BUFFER_LEN], max ;
+   sf_count_t  frames, readcount, k ;
+@@ -54,6 +55,8 @@ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int 
channels, int normalize
+   readcount = frames ;
+ 
+   sf_command (infile, SFC_CALC_SIGNAL_MAX, , sizeof (max)) ;
++  if (!isnormal (max)) /* neither zero, subnormal, infinite, nor NaN */
++  return 1 ;
+ 
+   if (!normalize && max < 1.0)
+   {   while (readcount > 0)
+@@ -67,12 +70,16 @@ sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int 
channels, int normalize
+   while (readcount > 0)
+   {   readcount = sf_readf_double (infile, data, frames) ;
+   for (k = 0 ; k < readcount * channels ; k++)
+-  data [k] /= max ;
++  {   data [k] /= max ;
++
++  if (!isfinite (data [k])) /* infinite or NaN */
++  return 1;
++  }
+   sf_writef_double (outfile, data, readcount) ;
+   } ;
+   } ;
+ 
+-  return ;
++  return 0 ;
+ } /* sfe_copy_data_fp */
+ 
+ void
+@@ -252,7 +259,12 @@ sfe_apply_metadata_changes (const char * filenames [2], 
const METADATA_INFO * in
+ 
+   /* If the input file is not the same as the output file, copy 
the data. */
+   if ((infileminor == SF_FORMAT_DOUBLE) || (infileminor == 
SF_FORMAT_FLOAT))
+-  sfe_copy_data_fp (outfile, infile, sfinfo.channels, 
SF_FALSE) ;
++  {   if (sfe_copy_data_fp (outfile, infile, sfinfo.channels, 
SF_FALSE) != 0)
++  {   printf ("Error : Not able to decode input file 
'%s'\n", filenames [0]) ;
++  error_code = 1 ;
++  goto cleanup_exit ;
++  } ;
++  }
+   else
+   sfe_copy_data_int (outfile, infile, sfinfo.channels) ;
+   } ;
+diff --git a/programs/common.h b/programs/common.h
+index eda2d7d..986277e 100644
+--- a/programs/common.h
 b/programs/common.h
+@@ -62,7 +62,7 @@ typedef SF_BROADCAST_INFO_VAR (2048) SF_BROADCAST_INFO_2K ;
+ 
+ void sfe_apply_metadata_changes (const char * filenames [2], const 
METADATA_INFO * info) ;
+ 
+-void sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize) ;
++int sfe_copy_data_fp (SNDFILE *outfile, SNDFILE *infile, int channels, int 
normalize) ;
+ 
+ void sfe_copy_data_int (SNDFILE *outfile, SNDFILE *infile, int channels) ;
+ 
+diff --git a/programs/sndfile-convert.c b/programs/sndfile-convert.c
+index dff7f79..e6de593 100644
+--- a/programs/sndfile-convert.c
 b/programs/sndfile-convert.c
+@@ -335,7 

[OE-core] [ROCKO][PATCH V3 02/34] busybox: CVE-2017-16544

[Jagadeesh Krishnanjanappa]

lineedit: do not tab-complete any strings which have control characters

function old new delta
add_match 41 68 +27

Affects busybox <= 1.27.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../busybox/busybox/CVE-2017-16544.patch   | 44 ++
 meta/recipes-core/busybox/busybox_1.24.1.bb|  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/CVE-2017-16544.patch

diff --git a/meta/recipes-core/busybox/busybox/CVE-2017-16544.patch 
b/meta/recipes-core/busybox/busybox/CVE-2017-16544.patch
new file mode 100644
index 000..8038886
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/CVE-2017-16544.patch
@@ -0,0 +1,44 @@
+From c3797d40a1c57352192c6106cc0f435e7d9c11e8 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Tue, 7 Nov 2017 18:09:29 +0100
+Subject: lineedit: do not tab-complete any strings which have control
+ characters
+
+function old new   delta
+add_match 41  68 +27
+
+CVE: CVE-2017-16544
+Upstream-Status: Backport from v1.28.0
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+Signed-off-by: Denys Vlasenko 
+---
+ libbb/lineedit.c | 12 
+ 1 file changed, 12 insertions(+)
+
+diff --git a/libbb/lineedit.c b/libbb/lineedit.c
+index c0e35bb..56e8140 100644
+--- a/libbb/lineedit.c
 b/libbb/lineedit.c
+@@ -645,6 +645,18 @@ static void free_tab_completion_data(void)
+ 
+ static void add_match(char *matched)
+ {
++  unsigned char *p = (unsigned char*)matched;
++  while (*p) {
++  /* ESC attack fix: drop any string with control chars */
++  if (*p < ' '
++   || (!ENABLE_UNICODE_SUPPORT && *p >= 0x7f)
++   || (ENABLE_UNICODE_SUPPORT && *p == 0x7f)
++  ) {
++  free(matched);
++  return;
++  }
++  p++;
++  }
+   matches = xrealloc_vector(matches, 4, num_matches);
+   matches[num_matches] = matched;
+   num_matches++;
+-- 
+cgit v0.12
+
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb 
b/meta/recipes-core/busybox/busybox_1.24.1.bb
index 1c85808..a2c0aa3 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -61,6 +61,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-tar-add-IF_FEATURE_-checks.patch \
file://0001-iproute-support-scope-.-Closes-8561.patch \

file://0001-ip-fix-an-improper-optimization-req.r.rtm_scope-may-.patch \
+   file://CVE-2017-16544.patch \
 "
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V3 01/34] sqlite3: CVE-2017-15286

[Jagadeesh Krishnanjanappa]

CVE-2017-15286: Make sure the tableColumnList() routine of the command-line
shell does not cause a null-pointer dereference in an error condition.

Affects sqlite3 < 3.21

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../sqlite/files/CVE-2017-15286.patch  | 34 ++
 meta/recipes-support/sqlite/sqlite3_3.20.0.bb  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2017-15286.patch

diff --git a/meta/recipes-support/sqlite/files/CVE-2017-15286.patch 
b/meta/recipes-support/sqlite/files/CVE-2017-15286.patch
new file mode 100644
index 000..954f8d5
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2017-15286.patch
@@ -0,0 +1,34 @@
+SQLite 3.20.1 has a NULL pointer dereference in tableColumnList in shell.c 
+because it fails to consider certain cases where 
+`sqlite3_step(pStmt)==SQLITE_ROW` is false and a data structure 
+is never initialized.
+
+This CVE patch applies neatly on sqlite v3.20.0, hence applying
+for sqlite v3.20.0.
+
+Also, removed hunk of "src/shell.c.in" present in upstream 
+commit https://www.sqlite.org/src/info/5d0ceb8dcdef92cd; as v3.20.0
+does not have src/shell.c.in file.
+
+CVE: CVE-2017-15286
+Upstream-Status: Backport from v3.21
+
+Signed-off-by: drh 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+
+Index: src/shell.c
+==
+--- src/shell.c
 src/shell.c
+@@ -3799,10 +3799,11 @@
+ isIPK = 0;
+   }
+ }
+   }
+   sqlite3_finalize(pStmt);
++  if( azCol==0 ) return 0;
+   azCol[0] = 0;
+   azCol[nCol+1] = 0;
+ 
+   /* The decision of whether or not a rowid really needs to be preserved
+   ** is tricky.  We never need to preserve a rowid for a WITHOUT ROWID table
diff --git a/meta/recipes-support/sqlite/sqlite3_3.20.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.20.0.bb
index e508258..1b82289 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.20.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.20.0.bb
@@ -6,6 +6,7 @@ LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
 SRC_URI = "\
   http://www.sqlite.org/2017/sqlite-autoconf-${SQLITE_PV}.tar.gz \
   file://sqlite3-fix-CVE-2017-13685.patch \
+  file://CVE-2017-15286.patch \
   "
 SRC_URI[md5sum] = "e262a28b73cc330e7e83520c8ce14e4d"
 SRC_URI[sha256sum] = 
"3814c6f629ff93968b2b37a70497cfe98b366bf587a2261a56a5f750af6ae6a0"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] mtd-utils: Revert "Return correct error number in ubi_get_vol_in"

[Adriana Kobylak]

> On Jul 30, 2018, at 12:56 PM, Adriana Kobylak  wrote:
> 
> Add mtd-utils upstream patch that fixes a regression on the
> mtd-utils tools such as ubinfo.
> 
> Details of the issue which affects mtd-utils 2.0.1 and 2.0.2:
> http://lists.infradead.org/pipermail/linux-mtd/2018-June/081562.html
> 
> Upstream-Status: Accepted 
> [http://git.infradead.org/mtd-utils.git/commit/0f833ac73ad631248826386e2918d8571ecf0347]
> 
> Signed-off-by: Adriana Kobylak 
> ---
> ...rn-correct-error-number-in-ubi_get_vol_in.patch | 92 ++
> meta/recipes-devtools/mtd/mtd-utils_git.bb |  1 +
> 2 files changed, 93 insertions(+)
> create mode 100644 
> meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
> 
> diff --git 
> a/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
>  
> b/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
> new file mode 100644
> index 000..4ece56b
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
> @@ -0,0 +1,92 @@
> +From 0f833ac73ad631248826386e2918d8571ecf0347 Mon Sep 17 00:00:00 2001
> +From: David Oberhollenzer 
> +Date: Sat, 9 Jun 2018 16:45:22 +0200
> +Subject: [PATCH] Revert "Return correct error number in ubi_get_vol_info1"
> +
> +This reverts commit dede98ffb706676309488d7cc660f569548d5930.
> +
> +The original commit tried to fix a descrepancy between the implementation
> +and the documentation by making the implementation comply.
> +
> +When making the change, it was overlooked, that ubinfo and ubirename were
> +written against the implementation instead of the behaviour specified by
> +the documentation. So were further internal functions like
> +ubi_get_vol_info1_nm which further breaks ubirmvol.
> +
> +A report with an outline of a resulting problem can be read on
> +the mailing list:
> +
> +http://lists.infradead.org/pipermail/linux-mtd/2018-June/081562.html
> +
> +From the report:
> +
> +steps to reproduce: have mtd-utils 2.0.1 or 2.0.2
> +
> +0. make a bunch of ubi volumes in sequential order
> +
> +ubimkvol /dev/ubi0 -s 64KiB -N test1
> +ubimkvol /dev/ubi0 -s 64KiB -N test2
> +ubimkvol /dev/ubi0 -s 64KiB -N test3
> +ubimkvol /dev/ubi0 -s 64KiB -N test4
> +..
> +
> +1. delete the test1 volume, making a hole in the volume table
> +
> +ubirmvol /dev/ubi0 -N test1
> +
> +2. try an affected tool (i.e. "ubirmvol /dev/ubi0 -N test4" )
> +
> + |root at mr24:/# ubirmvol /dev/ubi0 -N test4
> + |ubirmvol: error!: cannot find UBI volume "test4"
> + | error 19 (No such device)
> +
> +or "ubinfo -a"
> +
> + | root at mr24:/# ubinfo -a
> + | UBI version:1
> + | Count of UBI devices:   1
> + | UBI control device major/minor: 10:59
> + | Present UBI devices:ubi0
> + |
> + | ubi0
> + | Volumes count:   11
> + | Logical eraseblock size: 15872 bytes, 15.5 KiB
> + | Total amount of logical eraseblocks: 1952 (30982144 bytes, 29.5 MiB)
> + | Amount of available logical eraseblocks: 75 (1190400 bytes, 1.1 MiB)
> + | Maximum count of volumes 92
> + | Count of bad physical eraseblocks:   0
> + | Count of reserved physical eraseblocks:  40
> + | Current maximum erase counter value: 984
> + | Minimum input/output unit size:  512 bytes
> + | Character device major/minor:251:0
> + | ubinfo: error!: libubi failed to probe volume 5 on ubi0
> + |error 19 (No such device)
> + | Present volumes: 0, 1, 2, 3, 4root at mr24:/#
> +
> +Reported-by: Christian Lamparter 
> +Signed-off-by: David Oberhollenzer 
> +Upstream-Status: Accepted 
> [http://git.infradead.org/mtd-utils.git/commit/0f833ac73ad631248826386e2918d8571ecf0347]
> +---
> + lib/libubi.c | 5 +
> + 1 file changed, 1 insertion(+), 4 deletions(-)
> +
> +diff --git a/lib/libubi.c b/lib/libubi.c
> +index b50e68a..978b433 100644
> +--- a/lib/libubi.c
>  b/lib/libubi.c
> +@@ -1240,11 +1240,8 @@ int ubi_get_vol_info1(libubi_t desc, int dev_num, int 
> vol_id,
> + info->dev_num = dev_num;
> + info->vol_id = vol_id;
> + 
> +-if (vol_get_major(lib, dev_num, vol_id, >major, >minor)) {
> +-if (errno == ENOENT)
> +-errno = ENODEV;
> ++if (vol_get_major(lib, dev_num, vol_id, >major, >minor))
> + return -1;
> +-}
> + 
> + ret = vol_read_data(lib->vol_type, dev_num, vol_id, buf, 50);
> + if (ret < 0)
> +-- 
> +2.14.4
> +
> diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb 
> b/meta/recipes-devtools/mtd/mtd-utils_git.bb
> index 97a3e0c..f53c6c1 100644
> --- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
> +++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
> @@ -15,6 +15,7 @@ PV = "2.0.2+${SRCPV}"
> SRCREV = "bc63d36e39f389c8c17f6a8e9db47f2acc884659"
> SRC_URI = 

Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

[richard . purdie]

On Wed, 2018-08-22 at 15:39 +0200, Ricardo Ribalda Delgado wrote:
> On Wed, Aug 22, 2018 at 3:37 PM 
> wrote:
> > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > /libx32/ld-linux-x32.so.
> > 
> > I just looked at what the function is doing and its broken. What is
> > DEFAULTTUNE set to in your build?
> 
> DEFAULTTUNE="dbfp4"

As I suspected.

Try applying:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=d69f0127b44a5216dd21ad972d6f2b2e4cda6d13

and 

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=95aa56ae11852c100be68d13aaffa9c83273b46b

and then seen if that fixes things.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Bruce Ashfield]

On 08/22/2018 10:47 AM, Lukasz Majewski wrote:

On Wed, 22 Aug 2018 10:44:08 -0400
Bruce Ashfield  wrote:


On 08/22/2018 10:20 AM, Lukasz Majewski wrote:

On Wed, 22 Aug 2018 10:13:33 -0400
Bruce Ashfield  wrote:
   

On 08/22/2018 10:05 AM, Lukasz Majewski wrote:

Hi Bruce,
  

On 08/22/2018 09:40 AM, Lukasz Majewski wrote:

Without this patch it happens that do_populate_recipe_sysroot is
called just before do_compile (on multi core build machines).
This is way too late as the .config generated in
do_kernel_configme() is already broken.

The problem is that do_kernel_configme() calls native's
merge_config.sh script which may call bison and arm-linux-*-gcc
to compile kconfig infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after
do_prepare_recipe_sysroot() is called.
If those binaries are not available, the merge_config.sh do not
generate base .config and without any error produces
malfunctioned .config. The build process continues and as a
result broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel

(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
 meta/classes/kernel-yocto.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
100644 --- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] =
"kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs]
+= "${S} ${B}" +do_kernel_configme[depends] +=
"virtual/kernel:do_prepare_recipe_sysroot"


On a closer look .. what branch is this from ? We already have a
change that triggered breakage on 4.17+ that should fix this.

i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core,
adds:

--

 do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] =
"kern-tools-native:do_populate_sysroot"

+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
+do_kernel_configme[depends] += "bc-native:do_populate_sysroot
bison-native:do_populate_sysroot"
 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {

--

Which I don't see in the context of your patch.
 


I do use poky as in the commit message.


Yes, I checked that .. but that isn't a useful part of a patch
to oe-core.

The kernel-yocto bbclass in that context is not the one in master,
and if I run a --contains on that commit ID, I don't get an active
branch.


I might have misunderstood something... apparently.

The changes which I did were to:

poky/meta/classes/kernel-yocto.bbclass

Is this a wrong place to add the fix?


It is the right place to add the fix, but the tree that you are
using is not up to date with the current poky or oe-core master.

There are other changes in place that address a similar failure.

For us to look at this change, it needs to be rebased on top of
master (or master-next).


Now I got it. I shall sent the fix against cutting edge -master.

Shall I re-send the fix, of will you first check if patches in the
queue doesn't fix it already?


I'll run the steps in your reproducer and let you know if it
works here.

Bruce





Bruce

   


So the patch as it stands, cannot be applied to master (and I
also checked master-next in case something snuck in that I
missed) of oe-core or poky, so there's no way to work with it.

Bruce
  


Regarding the kernel - I do have my own recipe;
inherit kernel

require
recipes-kernel/linux/linux-yocto.inc


And then I do have:
COMPATIBLE_MACHINE_display5 = "display5"

KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
"imx6q_display5_defconfig"

As the board is in mainline I just point to Linus tree.
  

Bruce
 

 do_kernel_configme() {
set +e
 
 
 





Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang
Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
w...@denx.de
  





Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang
Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
w...@denx.de







Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: 

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Lukasz Majewski]

On Wed, 22 Aug 2018 10:44:08 -0400
Bruce Ashfield  wrote:

> On 08/22/2018 10:20 AM, Lukasz Majewski wrote:
> > On Wed, 22 Aug 2018 10:13:33 -0400
> > Bruce Ashfield  wrote:
> >   
> >> On 08/22/2018 10:05 AM, Lukasz Majewski wrote:  
> >>> Hi Bruce,
> >>>  
>  On 08/22/2018 09:40 AM, Lukasz Majewski wrote:  
> > Without this patch it happens that do_populate_recipe_sysroot is
> > called just before do_compile (on multi core build machines).
> > This is way too late as the .config generated in
> > do_kernel_configme() is already broken.
> >
> > The problem is that do_kernel_configme() calls native's
> > merge_config.sh script which may call bison and arm-linux-*-gcc
> > to compile kconfig infrastructure to create base .config
> > (scripts/kconfig/conf  --allnoconfig Kconfig.)
> >
> > It turns out that we only got above binaries after
> > do_prepare_recipe_sysroot() is called.
> > If those binaries are not available, the merge_config.sh do not
> > generate base .config and without any error produces
> > malfunctioned .config. The build process continues and as a
> > result broken kernel is compiled.
> >
> > To reproduce:
> >
> > bitbake -c cleansstate virtual/kernel
> > bitbake -c kernel_metadata -v virtual/kernel
> > bitbake -c do_kernel_configme -v virtual/kernel
> > (one shall see broken .config in ${B}/.config)
> > bitbake -c do_populate_sysroot -v virtual/kernel
> > bitbake -c do_compile -v virtual/kernel
> >
> > (Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d
> >
> > Signed-off-by: Lukasz Majewski 
> > ---
> > meta/classes/kernel-yocto.bbclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass
> > b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
> > 100644 --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
> > "kern-tools-native:do_populate_sysroot"
> > do_validate_branches[depends] =
> > "kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs]
> > += "${S} ${B}" +do_kernel_configme[depends] +=
> > "virtual/kernel:do_prepare_recipe_sysroot"  
> 
>  On a closer look .. what branch is this from ? We already have a
>  change that triggered breakage on 4.17+ that should fix this.
> 
>  i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core,
>  adds:
> 
>  --
> 
>  do_kernel_metadata[depends] =
>  "kern-tools-native:do_populate_sysroot"
>  do_validate_branches[depends] =
>  "kern-tools-native:do_populate_sysroot"
> 
>  +do_kernel_configme[depends] +=
>  "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
>  +do_kernel_configme[depends] +=
>  "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
>  +do_kernel_configme[depends] += "bc-native:do_populate_sysroot
>  bison-native:do_populate_sysroot"
>  do_kernel_configme[dirs] += "${S} ${B}"
>  do_kernel_configme() {
> 
>  --
> 
>  Which I don't see in the context of your patch.
>  
> >>>
> >>> I do use poky as in the commit message.  
> >>
> >> Yes, I checked that .. but that isn't a useful part of a patch
> >> to oe-core.
> >>
> >> The kernel-yocto bbclass in that context is not the one in master,
> >> and if I run a --contains on that commit ID, I don't get an active
> >> branch.  
> > 
> > I might have misunderstood something... apparently.
> > 
> > The changes which I did were to:
> > 
> > poky/meta/classes/kernel-yocto.bbclass
> > 
> > Is this a wrong place to add the fix?  
> 
> It is the right place to add the fix, but the tree that you are
> using is not up to date with the current poky or oe-core master.
> 
> There are other changes in place that address a similar failure.
> 
> For us to look at this change, it needs to be rebased on top of
> master (or master-next).

Now I got it. I shall sent the fix against cutting edge -master.

Shall I re-send the fix, of will you first check if patches in the
queue doesn't fix it already?

> 
> Bruce
> 
> >   
> >>
> >> So the patch as it stands, cannot be applied to master (and I
> >> also checked master-next in case something snuck in that I
> >> missed) of oe-core or poky, so there's no way to work with it.
> >>
> >> Bruce
> >>  
> >>>
> >>> Regarding the kernel - I do have my own recipe;
> >>> inherit kernel
> >>>
> >>> require
> >>> recipes-kernel/linux/linux-yocto.inc
> >>>
> >>>
> >>> And then I do have:
> >>> COMPATIBLE_MACHINE_display5 = "display5"
> >>>
> >>> KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
> >>> "imx6q_display5_defconfig"
> >>>
> >>> As the board is in mainline I just point to Linus tree.
> >>>  
>  Bruce
>  
> > do_kernel_configme() {
> > set +e
> > 

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Bruce Ashfield]

On 08/22/2018 10:20 AM, Lukasz Majewski wrote:

On Wed, 22 Aug 2018 10:13:33 -0400
Bruce Ashfield  wrote:


On 08/22/2018 10:05 AM, Lukasz Majewski wrote:

Hi Bruce,
   

On 08/22/2018 09:40 AM, Lukasz Majewski wrote:

Without this patch it happens that do_populate_recipe_sysroot is
called just before do_compile (on multi core build machines).
This is way too late as the .config generated in
do_kernel_configme() is already broken.

The problem is that do_kernel_configme() calls native's
merge_config.sh script which may call bison and arm-linux-*-gcc to
compile kconfig infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after
do_prepare_recipe_sysroot() is called.
If those binaries are not available, the merge_config.sh do not
generate base .config and without any error produces
malfunctioned .config. The build process continues and as a result
broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel

(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
meta/classes/kernel-yocto.bbclass | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
100644 --- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] =
"kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs]
+= "${S} ${B}" +do_kernel_configme[depends] +=
"virtual/kernel:do_prepare_recipe_sysroot"


On a closer look .. what branch is this from ? We already have a
change that triggered breakage on 4.17+ that should fix this.

i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core,
adds:

--

do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] =
"kern-tools-native:do_populate_sysroot"

+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
+do_kernel_configme[depends] += "bc-native:do_populate_sysroot
bison-native:do_populate_sysroot"
do_kernel_configme[dirs] += "${S} ${B}"
do_kernel_configme() {

--

Which I don't see in the context of your patch.
  


I do use poky as in the commit message.


Yes, I checked that .. but that isn't a useful part of a patch
to oe-core.

The kernel-yocto bbclass in that context is not the one in master, and
if I run a --contains on that commit ID, I don't get an active
branch.


I might have misunderstood something... apparently.

The changes which I did were to:

poky/meta/classes/kernel-yocto.bbclass

Is this a wrong place to add the fix?


It is the right place to add the fix, but the tree that you are
using is not up to date with the current poky or oe-core master.

There are other changes in place that address a similar failure.

For us to look at this change, it needs to be rebased on top of
master (or master-next).

Bruce





So the patch as it stands, cannot be applied to master (and I
also checked master-next in case something snuck in that I
missed) of oe-core or poky, so there's no way to work with it.

Bruce



Regarding the kernel - I do have my own recipe;
inherit kernel

require
recipes-kernel/linux/linux-yocto.inc


And then I do have:
COMPATIBLE_MACHINE_display5 = "display5"

KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
"imx6q_display5_defconfig"

As the board is in mainline I just point to Linus tree.
   

Bruce
  

do_kernel_configme() {
set +e

  
  





Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang
Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
w...@denx.de







Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Lukasz Majewski]

On Wed, 22 Aug 2018 10:13:33 -0400
Bruce Ashfield  wrote:

> On 08/22/2018 10:05 AM, Lukasz Majewski wrote:
> > Hi Bruce,
> >   
> >> On 08/22/2018 09:40 AM, Lukasz Majewski wrote:  
> >>> Without this patch it happens that do_populate_recipe_sysroot is
> >>> called just before do_compile (on multi core build machines).
> >>> This is way too late as the .config generated in
> >>> do_kernel_configme() is already broken.
> >>>
> >>> The problem is that do_kernel_configme() calls native's
> >>> merge_config.sh script which may call bison and arm-linux-*-gcc to
> >>> compile kconfig infrastructure to create base .config
> >>> (scripts/kconfig/conf  --allnoconfig Kconfig.)
> >>>
> >>> It turns out that we only got above binaries after
> >>> do_prepare_recipe_sysroot() is called.
> >>> If those binaries are not available, the merge_config.sh do not
> >>> generate base .config and without any error produces
> >>> malfunctioned .config. The build process continues and as a result
> >>> broken kernel is compiled.
> >>>
> >>> To reproduce:
> >>>
> >>> bitbake -c cleansstate virtual/kernel
> >>> bitbake -c kernel_metadata -v virtual/kernel
> >>> bitbake -c do_kernel_configme -v virtual/kernel
> >>> (one shall see broken .config in ${B}/.config)
> >>> bitbake -c do_populate_sysroot -v virtual/kernel
> >>> bitbake -c do_compile -v virtual/kernel
> >>>
> >>> (Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d
> >>>
> >>> Signed-off-by: Lukasz Majewski 
> >>> ---
> >>>meta/classes/kernel-yocto.bbclass | 1 +
> >>>1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/meta/classes/kernel-yocto.bbclass
> >>> b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
> >>> 100644 --- a/meta/classes/kernel-yocto.bbclass
> >>> +++ b/meta/classes/kernel-yocto.bbclass
> >>> @@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
> >>> "kern-tools-native:do_populate_sysroot"
> >>> do_validate_branches[depends] =
> >>> "kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs]
> >>> += "${S} ${B}" +do_kernel_configme[depends] +=
> >>> "virtual/kernel:do_prepare_recipe_sysroot"  
> >>
> >> On a closer look .. what branch is this from ? We already have a
> >> change that triggered breakage on 4.17+ that should fix this.
> >>
> >> i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core,
> >> adds:
> >>
> >> --
> >>
> >>do_kernel_metadata[depends] =
> >> "kern-tools-native:do_populate_sysroot"
> >> do_validate_branches[depends] =
> >> "kern-tools-native:do_populate_sysroot"
> >>
> >> +do_kernel_configme[depends] +=
> >> "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
> >> +do_kernel_configme[depends] +=
> >> "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
> >> +do_kernel_configme[depends] += "bc-native:do_populate_sysroot
> >> bison-native:do_populate_sysroot"
> >>do_kernel_configme[dirs] += "${S} ${B}"
> >>do_kernel_configme() {
> >>
> >> --
> >>
> >> Which I don't see in the context of your patch.
> >>  
> > 
> > I do use poky as in the commit message.  
> 
> Yes, I checked that .. but that isn't a useful part of a patch
> to oe-core.
> 
> The kernel-yocto bbclass in that context is not the one in master, and
> if I run a --contains on that commit ID, I don't get an active
> branch.

I might have misunderstood something... apparently.

The changes which I did were to:

poky/meta/classes/kernel-yocto.bbclass

Is this a wrong place to add the fix?

> 
> So the patch as it stands, cannot be applied to master (and I
> also checked master-next in case something snuck in that I
> missed) of oe-core or poky, so there's no way to work with it.
> 
> Bruce
> 
> > 
> > Regarding the kernel - I do have my own recipe;
> > inherit kernel
> > 
> > require
> > recipes-kernel/linux/linux-yocto.inc
> > 
> > 
> > And then I do have:
> > COMPATIBLE_MACHINE_display5 = "display5"
> > 
> > KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
> > "imx6q_display5_defconfig"
> > 
> > As the board is in mainline I just point to Linus tree.
> >   
> >> Bruce
> >>  
> >>>do_kernel_configme() {
> >>>   set +e
> >>>
> >>>  
> >>  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de 
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpKUFCqSg4k9.pgp
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Bruce Ashfield]

On 08/22/2018 10:05 AM, Lukasz Majewski wrote:

Hi Bruce,


On 08/22/2018 09:40 AM, Lukasz Majewski wrote:

Without this patch it happens that do_populate_recipe_sysroot is
called just before do_compile (on multi core build machines).
This is way too late as the .config generated in
do_kernel_configme() is already broken.

The problem is that do_kernel_configme() calls native's
merge_config.sh script which may call bison and arm-linux-*-gcc to
compile kconfig infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after
do_prepare_recipe_sysroot() is called.
If those binaries are not available, the merge_config.sh do not
generate base .config and without any error produces
malfunctioned .config. The build process continues and as a result
broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel

(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
   meta/classes/kernel-yocto.bbclass | 1 +
   1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
100644 --- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot"
do_validate_branches[depends] =
"kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs] +=
"${S} ${B}" +do_kernel_configme[depends] +=
"virtual/kernel:do_prepare_recipe_sysroot"


On a closer look .. what branch is this from ? We already have a
change that triggered breakage on 4.17+ that should fix this.

i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core, adds:

--

   do_kernel_metadata[depends] =
"kern-tools-native:do_populate_sysroot" do_validate_branches[depends]
= "kern-tools-native:do_populate_sysroot"

+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
+do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
+do_kernel_configme[depends] += "bc-native:do_populate_sysroot
bison-native:do_populate_sysroot"
   do_kernel_configme[dirs] += "${S} ${B}"
   do_kernel_configme() {

--

Which I don't see in the context of your patch.



I do use poky as in the commit message.


Yes, I checked that .. but that isn't a useful part of a patch
to oe-core.

The kernel-yocto bbclass in that context is not the one in master, and
if I run a --contains on that commit ID, I don't get an active
branch.

So the patch as it stands, cannot be applied to master (and I
also checked master-next in case something snuck in that I
missed) of oe-core or poky, so there's no way to work with it.

Bruce



Regarding the kernel - I do have my own recipe;
inherit kernel

require
recipes-kernel/linux/linux-yocto.inc


And then I do have:
COMPATIBLE_MACHINE_display5 = "display5"

KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
"imx6q_display5_defconfig"

As the board is in mainline I just point to Linus tree.


Bruce


   do_kernel_configme() {
set +e
   
   







Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for "[ROCKO,V2] sqlite3: CVE-2017-1..." and 33 more

[Patchwork]

== Series Details ==

Series: "[ROCKO,V2] sqlite3: CVE-2017-1..." and 33 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/13666/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[ROCKO,V2,16/34] Qemu CVE-2018-11806 
slirp-heap-buffer-overflow
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "

* Issue Upstream-Status is in incorrect format 
[test_upstream_status_presence_format] 
  Suggested fixFix Upstream-Status format in 
0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
  Current  Upstream-status: Backport 
[https://github.com/qemu/qemu/commit/864036e251f54c99d31df124aad7f34f01f5344c#diff-de3b23fd63b9e35d35c454525498d51c]
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Patchwork]

== Series Details ==

Series: kernel: yocto: Add dependency on do_prepare_recipe_sysroot
Revision: 1
URL   : https://patchwork.openembedded.org/series/13667/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at d2a929d932)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Lukasz Majewski]

Hi Bruce,

> On 08/22/2018 09:40 AM, Lukasz Majewski wrote:
> > Without this patch it happens that do_populate_recipe_sysroot is
> > called just before do_compile (on multi core build machines).
> > This is way too late as the .config generated in
> > do_kernel_configme() is already broken.
> > 
> > The problem is that do_kernel_configme() calls native's
> > merge_config.sh script which may call bison and arm-linux-*-gcc to
> > compile kconfig infrastructure to create base .config
> > (scripts/kconfig/conf  --allnoconfig Kconfig.)
> > 
> > It turns out that we only got above binaries after
> > do_prepare_recipe_sysroot() is called.
> > If those binaries are not available, the merge_config.sh do not
> > generate base .config and without any error produces
> > malfunctioned .config. The build process continues and as a result
> > broken kernel is compiled.
> > 
> > To reproduce:
> > 
> > bitbake -c cleansstate virtual/kernel
> > bitbake -c kernel_metadata -v virtual/kernel
> > bitbake -c do_kernel_configme -v virtual/kernel
> > (one shall see broken .config in ${B}/.config)
> > bitbake -c do_populate_sysroot -v virtual/kernel
> > bitbake -c do_compile -v virtual/kernel
> > 
> > (Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> >   meta/classes/kernel-yocto.bbclass | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/classes/kernel-yocto.bbclass
> > b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
> > 100644 --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
> > "kern-tools-native:do_populate_sysroot"
> > do_validate_branches[depends] =
> > "kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs] +=
> > "${S} ${B}" +do_kernel_configme[depends] +=
> > "virtual/kernel:do_prepare_recipe_sysroot"  
> 
> On a closer look .. what branch is this from ? We already have a
> change that triggered breakage on 4.17+ that should fix this.
> 
> i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core, adds:
> 
> --
> 
>   do_kernel_metadata[depends] =
> "kern-tools-native:do_populate_sysroot" do_validate_branches[depends]
> = "kern-tools-native:do_populate_sysroot"
> 
> +do_kernel_configme[depends] += 
> "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
> +do_kernel_configme[depends] += 
> "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
> +do_kernel_configme[depends] += "bc-native:do_populate_sysroot 
> bison-native:do_populate_sysroot"
>   do_kernel_configme[dirs] += "${S} ${B}"
>   do_kernel_configme() {
> 
> --
> 
> Which I don't see in the context of your patch.
> 

I do use poky as in the commit message.

Regarding the kernel - I do have my own recipe;
inherit kernel 

require
recipes-kernel/linux/linux-yocto.inc

   


And then I do have:
COMPATIBLE_MACHINE_display5 = "display5" 

KBUILD_DEFCONFIG_pn-linux-yocto-custom_display5 =
"imx6q_display5_defconfig"  

 

As the board is in mainline I just point to Linus tree.

> Bruce
> 
> >   do_kernel_configme() {
> > set +e
> >   
> >   
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgppJVKheNOBq.pgp
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Lukasz Majewski]

Hi Bruce,

> On 08/22/2018 09:40 AM, Lukasz Majewski wrote:
> > Without this patch it happens that do_populate_recipe_sysroot is
> > called just before do_compile (on multi core build machines).
> > This is way too late as the .config generated in
> > do_kernel_configme() is already broken.
> > 
> > The problem is that do_kernel_configme() calls native's
> > merge_config.sh script which may call bison and arm-linux-*-gcc to
> > compile kconfig infrastructure to create base .config
> > (scripts/kconfig/conf  --allnoconfig Kconfig.)
> > 
> > It turns out that we only got above binaries after
> > do_prepare_recipe_sysroot() is called.
> > If those binaries are not available, the merge_config.sh do not
> > generate base .config and without any error produces
> > malfunctioned .config. The build process continues and as a result
> > broken kernel is compiled.
> > 
> > To reproduce:
> > 
> > bitbake -c cleansstate virtual/kernel
> > bitbake -c kernel_metadata -v virtual/kernel
> > bitbake -c do_kernel_configme -v virtual/kernel
> > (one shall see broken .config in ${B}/.config)
> > bitbake -c do_populate_sysroot -v virtual/kernel
> > bitbake -c do_compile -v virtual/kernel
> >   
> 
> I already have a queue of changes for the 4.18 kernel that has a
> similar tweak.
> 
> I'll double check the use case above, and if it isn't already
> fixed, I'll add this to my queue.

One more strange observation the merge_config.sh shall use -native
binaries (like bison, gcc, etc).

Unfortunately, in my case it depends on target ones (as we do have
CFLAGS =  ARCH=arm ... merge_configs.sh).

The bitbake -g -u taskexp virtual/kernel shows however that we do
depend on native bison.

To provide target ones - I do need the do_prepare_recipe_sysroot() to
call before do_configure.

> 
> Bruce
> 
> > (Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> >   meta/classes/kernel-yocto.bbclass | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/classes/kernel-yocto.bbclass
> > b/meta/classes/kernel-yocto.bbclass index 4ac3a39e47..19a3f2bc46
> > 100644 --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -276,6 +276,7 @@ do_kernel_metadata[depends] =
> > "kern-tools-native:do_populate_sysroot"
> > do_validate_branches[depends] =
> > "kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs] +=
> > "${S} ${B}" +do_kernel_configme[depends] +=
> > "virtual/kernel:do_prepare_recipe_sysroot" do_kernel_configme() {
> > set +e
> >   
> >   
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpvXHLp3o_p4.pgp
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Bruce Ashfield]

On 08/22/2018 09:40 AM, Lukasz Majewski wrote:

Without this patch it happens that do_populate_recipe_sysroot is called
just before do_compile (on multi core build machines).
This is way too late as the .config generated in do_kernel_configme()
is already broken.

The problem is that do_kernel_configme() calls native's merge_config.sh
script which may call bison and arm-linux-*-gcc to compile kconfig
infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after do_prepare_recipe_sysroot()
is called.
If those binaries are not available, the merge_config.sh do not generate
base .config and without any error produces malfunctioned .config.
The build process continues and as a result broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel

(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
  meta/classes/kernel-yocto.bbclass | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 4ac3a39e47..19a3f2bc46 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] = 
"kern-tools-native:do_populate_sysroot"
  do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
  
  do_kernel_configme[dirs] += "${S} ${B}"

+do_kernel_configme[depends] += "virtual/kernel:do_prepare_recipe_sysroot"


On a closer look .. what branch is this from ? We already have a
change that triggered breakage on 4.17+ that should fix this.

i.e. commit ff1bdd75d50f0ebac3d599e461685ace29559a82 in oe-core, adds:

--

 do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot"
 do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"

+do_kernel_configme[depends] += 
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
+do_kernel_configme[depends] += 
"virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
+do_kernel_configme[depends] += "bc-native:do_populate_sysroot 
bison-native:do_populate_sysroot"

 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {

--

Which I don't see in the context of your patch.

Bruce


  do_kernel_configme() {
set +e
  



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Bruce Ashfield]

On 08/22/2018 09:40 AM, Lukasz Majewski wrote:

Without this patch it happens that do_populate_recipe_sysroot is called
just before do_compile (on multi core build machines).
This is way too late as the .config generated in do_kernel_configme()
is already broken.

The problem is that do_kernel_configme() calls native's merge_config.sh
script which may call bison and arm-linux-*-gcc to compile kconfig
infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after do_prepare_recipe_sysroot()
is called.
If those binaries are not available, the merge_config.sh do not generate
base .config and without any error produces malfunctioned .config.
The build process continues and as a result broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel



I already have a queue of changes for the 4.18 kernel that has a
similar tweak.

I'll double check the use case above, and if it isn't already
fixed, I'll add this to my queue.

Bruce


(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
  meta/classes/kernel-yocto.bbclass | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 4ac3a39e47..19a3f2bc46 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] = 
"kern-tools-native:do_populate_sysroot"
  do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
  
  do_kernel_configme[dirs] += "${S} ${B}"

+do_kernel_configme[depends] += "virtual/kernel:do_prepare_recipe_sysroot"
  do_kernel_configme() {
set +e
  



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kernel: yocto: Add dependency on do_prepare_recipe_sysroot

[Lukasz Majewski]

Without this patch it happens that do_populate_recipe_sysroot is called
just before do_compile (on multi core build machines).
This is way too late as the .config generated in do_kernel_configme()
is already broken.

The problem is that do_kernel_configme() calls native's merge_config.sh
script which may call bison and arm-linux-*-gcc to compile kconfig
infrastructure to create base .config
(scripts/kconfig/conf  --allnoconfig Kconfig.)

It turns out that we only got above binaries after do_prepare_recipe_sysroot()
is called.
If those binaries are not available, the merge_config.sh do not generate
base .config and without any error produces malfunctioned .config.
The build process continues and as a result broken kernel is compiled.

To reproduce:

bitbake -c cleansstate virtual/kernel
bitbake -c kernel_metadata -v virtual/kernel
bitbake -c do_kernel_configme -v virtual/kernel
(one shall see broken .config in ${B}/.config)
bitbake -c do_populate_sysroot -v virtual/kernel
bitbake -c do_compile -v virtual/kernel

(Poky) SHA1: bb91b2ae3ee5cf108aa2f9b78abb14d5aa00831d

Signed-off-by: Lukasz Majewski 
---
 meta/classes/kernel-yocto.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 4ac3a39e47..19a3f2bc46 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -276,6 +276,7 @@ do_kernel_metadata[depends] = 
"kern-tools-native:do_populate_sysroot"
 do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
 
 do_kernel_configme[dirs] += "${S} ${B}"
+do_kernel_configme[depends] += "virtual/kernel:do_prepare_recipe_sysroot"
 do_kernel_configme() {
set +e
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

[richard . purdie]

On Wed, 2018-08-22 at 15:33 +0200, Ricardo Ribalda Delgado wrote:
> Hello
> On Wed, Aug 22, 2018 at 3:28 PM Ricardo Ribalda Delgado
>  wrote:
> > 
> > On Wed, Aug 22, 2018 at 3:21 PM  > > wrote:
> > > 
> > > On Wed, 2018-08-22 at 15:13 +0200, Ricardo Ribalda Delgado wrote:
> > > > > Here I see:
> > > > > 
> > > > > $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> > > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > > 
> > > > The output of RTLDLIST that I shared was from
> > > > root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
> > > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > > /libx32/ld-linux-x32.so.2"
> > > > 
> > > > If I run your command
> > > > 
> > > > pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep
> > > > ^RTLDLIST=
> > > > RTLDLIST=""
> > > > 
> > > > If we look at log.do_compile we can see how the the value from
> > > > ldd is
> > > > rewritten:
> > > > 
> > > > LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
> > > > 's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
> > > > 's|@REPORT_BUGS_TO@| > > > >|g'
> > > > -e
> > > > 's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%
> > > > g' <
> > > > ldd.bash.in | LC_ALL=C sed -f
> > > > ../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
> > > > /workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-
> > > > x86_64-
> > > > poky-linux/elf/ldd.new
> > > > 
> > > > cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > > > /LD_TRACE_LOADED_OBJECTS=1/a\
> > > > add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> > > > s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-
> > > > x32\)\(\.so\.[0-9.]*\)[
> > > > ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
> > > > 
> > > > which basically converts
> > > > /lib/ld-linux-x86-64.so.2
> > > >  into:
> > > >  /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-
> > > > linux-
> > > > x32.so.2
> > > > 
> > > > I agree that this bug is too obvious for not being noticed for
> > > > a long
> > > > time. At least I use ldd a lot when thing fails ;)
> > > 
> > > If you look at glibc_2.28.bb, it rewrites RTLDLIST if the value
> > > passed
> > > in is not empty. Yours is empty, the question is therefore why.
> > > 
> > > Can you add -C10 to the command and see the variable history,
> > > here its:
> > > 
> > > # $RTLDLIST [2 operations]
> > > #   set /media/build3/poky/meta/recipes-core/glibc/glibc-
> > > ld.inc:46
> > > # "${@glibc_dl_info(d)['lddrewrite']}"
> > > #   override[class-nativesdk]:set
> > > /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > # pre-expansion value:
> > > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > 
> > 
> > 
> > # $RTLDLIST [2 operations]
> > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> > # "${@glibc_dl_info(d)['lddrewrite']}"
> > #   override[class-nativesdk]:set
> > /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > # pre-expansion value:
> > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > RTLDLIST=""
> > #
> > 
> > # $RTLDLIST_class-nativesdk
> > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > RTLDLIST_class-nativesdk="/lib/ld-linux-x86-64.so.2"
> > 
> > 
> > I have just upgraded my work build to 19.0.1 / 2.5.1 Let me build
> > ldd
> > again to see if the problem still persists
> 
> 19.0.1 gives the same results as 19.0.0
> 
> 
> RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> /libx32/ld-linux-x32.so.

I just looked at what the function is doing and its broken. What is
DEFAULTTUNE set to in your build?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 33/34] perl: CVE-2018-12015

[Jagadeesh Krishnanjanappa]

Remove existing files before overwriting them

Archive should extract only the latest same-named entry.
Extracted regular file should not be writtent into existing block
device (or any other one).

https://rt.cpan.org/Ticket/Display.html?id=125523

Affects perl <= 5.26.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../perl/perl/CVE-2018-12015.patch | 48 ++
 meta/recipes-devtools/perl/perl_5.24.1.bb  |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-12015.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
new file mode 100644
index 000..a2b0109
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-12015.patch
@@ -0,0 +1,48 @@
+From ae65651eab053fc6dc4590dbb863a268215c1fc5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Fri, 8 Jun 2018 11:45:40 +0100
+Subject: [PATCH] [PATCH] Remove existing files before overwriting them
+
+Archive should extract only the latest same-named entry.
+Extracted regular file should not be writtent into existing block
+device (or any other one).
+
+https://rt.cpan.org/Ticket/Display.html?id=125523
+
+CVE: CVE-2018-12015
+Upstream-Status: Backport 
[https://github.com/jib/archive-tar-new/commit/ae65651eab053fc6dc4590dbb863a268215c1fc5]
+
+Signed-off-by: Chris 'BinGOs' Williams 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/Archive/Tar.pm | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/cpan/Archive-Tar/lib/Archive/Tar.pm 
b/cpan/Archive-Tar/lib/Archive/Tar.pm
+index 6244369..a83975f 100644
+--- a/cpan/Archive-Tar/lib/Archive/Tar.pm
 b/cpan/Archive-Tar/lib/Archive/Tar.pm
+@@ -845,6 +845,20 @@ sub _extract_file {
+ return;
+ }
+ 
++### If a file system already contains a block device with the same name as
++### the being extracted regular file, we would write the file's content
++### to the block device. So remove the existing file (block device) now.
++### If an archive contains multiple same-named entries, the last one
++### should replace the previous ones. So remove the old file now.
++### If the old entry is a symlink to a file outside of the CWD, the new
++### entry would create a file there. This is CVE-2018-12015
++### .
++if (-l $full || -e _) {
++  if (!unlink $full) {
++  $self->_error( qq[Could not remove old file '$full': $!] );
++  return;
++  }
++}
+ if( length $entry->type && $entry->is_file ) {
+ my $fh = IO::File->new;
+ $fh->open( $full, '>' ) or (
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb 
b/meta/recipes-devtools/perl/perl_5.24.1.bb
index aec30c8..8dfe34a 100644
--- a/meta/recipes-devtools/perl/perl_5.24.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
@@ -72,6 +72,7 @@ SRC_URI += " \
 file://CVE-2018-6798-2.patch \
 file://CVE-2018-6797.patch \
 file://CVE-2018-6913.patch \
+file://CVE-2018-12015.patch \
 "
 
 # Fix test case issues
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

[Ricardo Ribalda Delgado]

Hi


On Wed, Aug 22, 2018 at 3:37 PM  wrote:
>
> On Wed, 2018-08-22 at 15:33 +0200, Ricardo Ribalda Delgado wrote:
> > Hello
> > On Wed, Aug 22, 2018 at 3:28 PM Ricardo Ribalda Delgado
> >  wrote:
> > >
> > > On Wed, Aug 22, 2018 at 3:21 PM  > > > wrote:
> > > >
> > > > On Wed, 2018-08-22 at 15:13 +0200, Ricardo Ribalda Delgado wrote:
> > > > > > Here I see:
> > > > > >
> > > > > > $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> > > > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > > >
> > > > > The output of RTLDLIST that I shared was from
> > > > > root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
> > > > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > > > /libx32/ld-linux-x32.so.2"
> > > > >
> > > > > If I run your command
> > > > >
> > > > > pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep
> > > > > ^RTLDLIST=
> > > > > RTLDLIST=""
> > > > >
> > > > > If we look at log.do_compile we can see how the the value from
> > > > > ldd is
> > > > > rewritten:
> > > > >
> > > > > LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
> > > > > 's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
> > > > > 's|@REPORT_BUGS_TO@| > > > > >|g'
> > > > > -e
> > > > > 's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%
> > > > > g' <
> > > > > ldd.bash.in | LC_ALL=C sed -f
> > > > > ../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
> > > > > /workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-
> > > > > x86_64-
> > > > > poky-linux/elf/ldd.new
> > > > >
> > > > > cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > > > > /LD_TRACE_LOADED_OBJECTS=1/a\
> > > > > add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> > > > > s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-
> > > > > x32\)\(\.so\.[0-9.]*\)[
> > > > > ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
> > > > >
> > > > > which basically converts
> > > > > /lib/ld-linux-x86-64.so.2
> > > > >  into:
> > > > >  /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-
> > > > > linux-
> > > > > x32.so.2
> > > > >
> > > > > I agree that this bug is too obvious for not being noticed for
> > > > > a long
> > > > > time. At least I use ldd a lot when thing fails ;)
> > > >
> > > > If you look at glibc_2.28.bb, it rewrites RTLDLIST if the value
> > > > passed
> > > > in is not empty. Yours is empty, the question is therefore why.
> > > >
> > > > Can you add -C10 to the command and see the variable history,
> > > > here its:
> > > >
> > > > # $RTLDLIST [2 operations]
> > > > #   set /media/build3/poky/meta/recipes-core/glibc/glibc-
> > > > ld.inc:46
> > > > # "${@glibc_dl_info(d)['lddrewrite']}"
> > > > #   override[class-nativesdk]:set
> > > > /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > > # pre-expansion value:
> > > > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > >
> > >
> > >
> > > # $RTLDLIST [2 operations]
> > > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> > > # "${@glibc_dl_info(d)['lddrewrite']}"
> > > #   override[class-nativesdk]:set
> > > /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > # pre-expansion value:
> > > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > > RTLDLIST=""
> > > #
> > >
> > > # $RTLDLIST_class-nativesdk
> > > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > RTLDLIST_class-nativesdk="/lib/ld-linux-x86-64.so.2"
> > >
> > >
> > > I have just upgraded my work build to 19.0.1 / 2.5.1 Let me build
> > > ldd
> > > again to see if the problem still persists
> >
> > 19.0.1 gives the same results as 19.0.0
> >
> >
> > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > /libx32/ld-linux-x32.so.
>
> I just looked at what the function is doing and its broken. What is
> DEFAULTTUNE set to in your build?

DEFAULTTUNE="dbfp4"

>
> Cheers,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 32/34] openssl: CVE-2018-0732

[Jagadeesh Krishnanjanappa]

Reject excessively large primes in DH key generation.

CVE-2018-0732

Affects openssl 1.0.2 to 1.0.2o

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../openssl/openssl-1.0.2o/CVE-2018-0732.patch | 46 ++
 .../recipes-connectivity/openssl/openssl_1.0.2o.bb |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch 
b/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch
new file mode 100644
index 000..d4d0bb4
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl-1.0.2o/CVE-2018-0732.patch
@@ -0,0 +1,46 @@
+From 3984ef0b72831da8b3ece4745cac4f8575b19098 Mon Sep 17 00:00:00 2001
+From: Guido Vranken 
+Date: Mon, 11 Jun 2018 19:38:54 +0200
+Subject: [PATCH] Reject excessively large primes in DH key generation.
+
+CVE: CVE-2018-0732
+
+Signed-off-by: Guido Vranken 
+
+(cherry picked from commit 91f7361f47b082ae61ffe1a7b17bb2adf213c7fe)
+
+Reviewed-by: Tim Hudson 
+Reviewed-by: Matt Caswell 
+(Merged from https://github.com/openssl/openssl/pull/6457)
+
+Upstream-Status: Backport 
[https://github.com/openssl/openssl/commit/ea7abeeabf92b7aca160bdd0208636d4da69f4f4]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ crypto/dh/dh_key.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/dh/dh_key.c b/crypto/dh/dh_key.c
+index 387558f146..f235e0d682 100644
+--- a/crypto/dh/dh_key.c
 b/crypto/dh/dh_key.c
+@@ -130,10 +130,15 @@ static int generate_key(DH *dh)
+ int ok = 0;
+ int generate_new_key = 0;
+ unsigned l;
+-BN_CTX *ctx;
++BN_CTX *ctx = NULL;
+ BN_MONT_CTX *mont = NULL;
+ BIGNUM *pub_key = NULL, *priv_key = NULL;
+ 
++if (BN_num_bits(dh->p) > OPENSSL_DH_MAX_MODULUS_BITS) {
++DHerr(DH_F_GENERATE_KEY, DH_R_MODULUS_TOO_LARGE);
++return 0;
++}
++
+ ctx = BN_CTX_new();
+ if (ctx == NULL)
+ goto err;
+-- 
+2.13.3
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
index 413ebf3..57912a1 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
@@ -41,6 +41,7 @@ SRC_URI += "file://find.pl;subdir=openssl-${PV}/util/ \
file://Use-SHA256-not-MD5-as-default-digest.patch \
file://0001-Fix-build-with-clang-using-external-assembler.patch \
file://0001-openssl-force-soft-link-to-avoid-rare-race.patch \
+   file://CVE-2018-0732.patch \
"
 
 SRC_URI_append_class-target = "\
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 34/34] libgcrypt: CVE-2018-0495

[Jagadeesh Krishnanjanappa]

ecc: Add blinding for ECDSA.

* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Blind secret D with
randomized nonce B.

--

CVE-id: CVE-2018-0495

Affects libgcrypt < 1.7.10 and libgcrypt < 1.8.3

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libgcrypt/files/CVE-2018-0495.patch| 76 ++
 meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb  |  1 +
 2 files changed, 77 insertions(+)
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch

diff --git a/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch 
b/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch
new file mode 100644
index 000..c16bd3a
--- /dev/null
+++ b/meta/recipes-support/libgcrypt/files/CVE-2018-0495.patch
@@ -0,0 +1,76 @@
+From 9010d1576e278a4274ad3f4aa15776c28f6ba965 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka 
+Date: Wed, 13 Jun 2018 15:28:58 +0900
+Subject: [PATCH] ecc: Add blinding for ECDSA.
+
+* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Blind secret D with
+randomized nonce B.
+
+--
+
+Reported-by: Keegan Ryan 
+CVE-id: CVE-2018-0495
+
+Upstream-Status: Backport 
[http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=9010d1576e278a4274ad3f4aa15776c28f6ba965]
+
+Signed-off-by: NIIBE Yutaka 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ cipher/ecc-ecdsa.c | 20 ++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
+index 1484830b..140e8c09 100644
+--- a/cipher/ecc-ecdsa.c
 b/cipher/ecc-ecdsa.c
+@@ -50,6 +50,8 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key *skey,
+   const void *abuf;
+   unsigned int abits, qbits;
+   mpi_ec_t ctx;
++  gcry_mpi_t b;/* Random number needed for blinding.  */
++  gcry_mpi_t bi;   /* multiplicative inverse of B.*/
+ 
+   if (DBG_CIPHER)
+ log_mpidump ("ecdsa sign hash  ", input );
+@@ -61,6 +63,15 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+   if (rc)
+ return rc;
+ 
++  b  = mpi_snew (qbits);
++  bi = mpi_snew (qbits);
++  do
++{
++  _gcry_mpi_randomize (b, qbits, GCRY_WEAK_RANDOM);
++  mpi_mod (b, b, skey->E.n);
++}
++  while (!mpi_invm (bi, b, skey->E.n));
++
+   k = NULL;
+   dr = mpi_alloc (0);
+   sum = mpi_alloc (0);
+@@ -115,8 +126,11 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+ }
+   while (!mpi_cmp_ui (r, 0));
+ 
+-  mpi_mulm (dr, skey->d, r, skey->E.n); /* dr = d*r mod n  */
+-  mpi_addm (sum, hash, dr, skey->E.n);  /* sum = hash + (d*r) mod n  */
++  mpi_mulm (dr, b, skey->d, skey->E.n);
++  mpi_mulm (dr, dr, r, skey->E.n);  /* dr = d*r mod n (blinded with 
b) */
++  mpi_mulm (sum, b, hash, skey->E.n);
++  mpi_addm (sum, sum, dr, skey->E.n);   /* sum = hash + (d*r) mod n  
(blinded with b) */
++  mpi_mulm (sum, bi, sum, skey->E.n);   /* undo blinding by b^-1 */
+   mpi_invm (k_1, k, skey->E.n); /* k_1 = k^(-1) mod n  */
+   mpi_mulm (s, k_1, sum, skey->E.n);/* s = k^(-1)*(hash+(d*r)) mod n 
*/
+ }
+@@ -129,6 +143,8 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+ }
+ 
+  leave:
++  mpi_free (b);
++  mpi_free (bi);
+   _gcry_mpi_ec_free (ctx);
+   point_free ();
+   mpi_free (x);
+-- 
+2.13.3
+
diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
index 02982f0..3d189f5 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.0.bb
@@ -22,6 +22,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \

file://0004-tests-Makefile.am-fix-undefined-reference-to-pthread.patch \
file://0005-ecc-Add-input-validation-for-X25519.patch \

file://0006-Fix-building-AArch32-CE-implementations-when-target-.patch \
+   file://CVE-2018-0495.patch \
 "
 SRC_URI[md5sum] = "110ce4352f9ea6f560bdc6c5644ae93c"
 SRC_URI[sha256sum] = 
"f6e470b7f2d3a703e8747f05a8c19d9e10e26ebf2d5f3d71ff75a40f504e12ee"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 31/34] git: CVE-2018-11235

[Jagadeesh Krishnanjanappa]

submodule-config: verify submodule names as paths

Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).

Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:

  1. What should the allowed syntax be?

 It's tempting to reuse verify_path(), since submodule
 names typically come from in-repo paths. But there are
 two reasons not to:

   a. It's technically more strict than what we need, as
  we really care only about breaking out of the
  $GIT_DIR/modules/ hierarchy.  E.g., having a
  submodule named "foo/.git" isn't actually
  dangerous, and it's possible that somebody has
  manually given such a funny name.

   b. Since we'll eventually use this checking logic in
  fsck to prevent downstream repositories, it should
  be consistent across platforms. Because
  verify_path() relies on is_dir_sep(), it wouldn't
  block "foo\..\bar" on a non-Windows machine.

  2. Where should we enforce it? These days most of the
 .gitmodules reads go through submodule-config.c, so
 I've put it there in the reading step. That should
 cover all of the C code.

 We also construct the name for "git submodule add"
 inside the git-submodule.sh script. This is probably
 not a big deal for security since the name is coming
 from the user anyway, but it would be polite to remind
 them if the name they pick is invalid (and we need to
 expose the name-checker to the shell anyway for our
 test scripts).

 This patch issues a warning when reading .gitmodules
 and just ignores the related config entry completely.
 This will generally end up producing a sensible error,
 as it works the same as a .gitmodules file which is
 missing a submodule entry (so "submodule update" will
 barf, but "git clone --recurse-submodules" will print
 an error but not abort the clone.

 There is one minor oddity, which is that we print the
 warning once per malformed config key (since that's how
 the config subsystem gives us the entries). So in the
 new test, for example, the user would see three
 warnings. That's OK, since the intent is that this case
 should never come up outside of malicious repositories
 (and then it might even benefit the user to see the
 message multiple times).

Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.

Affects: git < 2.13.7 and  git < 2.14.4 and git < 2.15.2 and git < 2.16.4 and
 git < 2.17.1

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../git/files/CVE-2018-11235.patch | 288 +
 meta/recipes-devtools/git/git.inc  |   3 +-
 2 files changed, 290 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/files/CVE-2018-11235.patch

diff --git a/meta/recipes-devtools/git/files/CVE-2018-11235.patch 
b/meta/recipes-devtools/git/files/CVE-2018-11235.patch
new file mode 100644
index 000..b774d2f
--- /dev/null
+++ b/meta/recipes-devtools/git/files/CVE-2018-11235.patch
@@ -0,0 +1,288 @@
+From 0383bbb9015898cbc79abd7b64316484d7713b44 Mon Sep 17 00:00:00 2001
+From: Jeff King 
+Date: Mon, 30 Apr 2018 03:25:25 -0400
+Subject: [PATCH] submodule-config: verify submodule names as paths
+
+Submodule "names" come from the untrusted .gitmodules file,
+but we blindly append them to $GIT_DIR/modules to create our
+on-disk repo paths. This means you can do bad things by
+putting "../" into the name (among other things).
+
+Let's sanity-check these names to avoid building a path that
+can be exploited. There are two main decisions:
+
+  1. What should the allowed syntax be?
+
+ It's tempting to reuse verify_path(), since submodule
+ names typically come from in-repo paths. But there are
+ two reasons not to:
+
+   a. It's technically more strict than what we need, as
+  we really care only about breaking out of the
+  $GIT_DIR/modules/ hierarchy.  E.g., having a
+  submodule named "foo/.git" isn't actually
+  dangerous, and it's possible that somebody has
+  manually given such a funny name.
+
+   b. Since we'll eventually use this checking logic in
+  fsck to prevent downstream repositories, it should
+  be consistent across platforms. Because
+  verify_path() relies on is_dir_sep(), it wouldn't
+  block "foo\..\bar" on a non-Windows machine.
+
+  2. Where should we enforce it? These days most of the
+ .gitmodules reads go through submodule-config.c, so
+ I've put it there in the reading step. That should
+ cover all of the C code.
+
+ We also construct the name for "git 

[OE-core] [ROCKO][PATCH V2 30/34] flac: CVE-2017-6888

[Jagadeesh Krishnanjanappa]

stream_decoder.c: Fix a memory leak

Leak reported by Secunia Research.

Affects flac = 1.3.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../flac/files/CVE-2017-6888.patch | 31 ++
 meta/recipes-multimedia/flac/flac_1.3.2.bb |  3 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/flac/files/CVE-2017-6888.patch

diff --git a/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch 
b/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch
new file mode 100644
index 000..389ab96
--- /dev/null
+++ b/meta/recipes-multimedia/flac/files/CVE-2017-6888.patch
@@ -0,0 +1,31 @@
+From 4f47b63e9c971e6391590caf00a0f2a5ed612e67 Mon Sep 17 00:00:00 2001
+From: Erik de Castro Lopo 
+Date: Sat, 8 Apr 2017 18:34:49 +1000
+Subject: [PATCH] stream_decoder.c: Fix a memory leak
+
+Leak reported by Secunia Research.
+CVE: CVE-2017-6888
+Upstream-Status: Backport 
[https://git.xiph.org/?p=flac.git;a=commitdiff;h=4f47b63e9c971e6391590caf00a0f2a5ed612e67]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/libFLAC/stream_decoder.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
+index 14d5fe7f..a5527511 100644
+--- a/src/libFLAC/stream_decoder.c
 b/src/libFLAC/stream_decoder.c
+@@ -1753,6 +1753,9 @@ FLAC__bool 
read_metadata_vorbiscomment_(FLAC__StreamDecoder *decoder, FLAC__Stre
+   }
+   memset (obj->comments[i].entry, 0, 
obj->comments[i].length) ;
+   if 
(!FLAC__bitreader_read_byte_block_aligned_no_crc(decoder->private_->input, 
obj->comments[i].entry, obj->comments[i].length)) {
++  /* Current i-th entry is bad, 
so we delete it. */
++  free (obj->comments[i].entry) ;
++  obj->comments[i].entry = NULL ;
+   obj->num_comments = i;
+   goto skip;
+   }
+-- 
+2.13.3
+
diff --git a/meta/recipes-multimedia/flac/flac_1.3.2.bb 
b/meta/recipes-multimedia/flac/flac_1.3.2.bb
index 8315ab5..028a429 100644
--- a/meta/recipes-multimedia/flac/flac_1.3.2.bb
+++ b/meta/recipes-multimedia/flac/flac_1.3.2.bb
@@ -14,7 +14,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING.FDL;md5=ad1419ecc56e060eccf8184a87c4285f \
 
file://include/FLAC/all.h;beginline=65;endline=70;md5=64474f2b22e9e77b28d8b8b25c983a48"
 DEPENDS = "libogg"
 
-SRC_URI = "http://downloads.xiph.org/releases/flac/${BP}.tar.xz;
+SRC_URI = "http://downloads.xiph.org/releases/flac/${BP}.tar.xz \
+   file://CVE-2017-6888.patch"
 
 SRC_URI[md5sum] = "454f1bfa3f93cc708098d7890d0499bd"
 SRC_URI[sha256sum] = 
"91cfc3ed61dc40f47f050a109b08610667d73477af6ef36dcad31c31a4a8d53f"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 29/34] wget: CVE-2018-0494

[Jagadeesh Krishnanjanappa]

Fix cookie injection (CVE-2018-0494)
* src/http.c (resp_new): Replace \r\n by space in continuation lines

Fixes #53763
 "Malicious website can write arbitrary cookie entries to cookie jar"

HTTP header parsing left the \r\n from continuation line intact.
The Set-Cookie code didn't check and could be tricked to write
\r\n into the cookie jar, allowing a server to generate cookies at will.

Affects wget < 1.19.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../0001-Fix-cookie-injection-CVE-2018-0494.patch  | 68 ++
 meta/recipes-extended/wget/wget_1.19.1.bb  |  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 
meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch

diff --git 
a/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch 
b/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch
new file mode 100644
index 000..ac163e6
--- /dev/null
+++ 
b/meta/recipes-extended/wget/wget/0001-Fix-cookie-injection-CVE-2018-0494.patch
@@ -0,0 +1,68 @@
+From 1fc9c95ec144499e69dc8ec76dbe07799d7d82cd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
+Date: Fri, 27 Apr 2018 10:41:56 +0200
+Subject: [PATCH] Fix cookie injection (CVE-2018-0494)
+
+* src/http.c (resp_new): Replace \r\n by space in continuation lines
+
+Fixes #53763
+ "Malicious website can write arbitrary cookie entries to cookie jar"
+
+HTTP header parsing left the \r\n from continuation line intact.
+The Set-Cookie code didn't check and could be tricked to write
+\r\n into the cookie jar, allowing a server to generate cookies at will.
+
+CVE: CVE-2018-0494
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/wget.git/commit/?id=1fc9c95ec144499e69dc8ec76dbe07799d7d82cd]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/http.c | 18 +-
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+diff --git a/src/http.c b/src/http.c
+index c8960f11..77bdbbed 100644
+--- a/src/http.c
 b/src/http.c
+@@ -613,9 +613,9 @@ struct response {
+resp_header_*.  */
+ 
+ static struct response *
+-resp_new (const char *head)
++resp_new (char *head)
+ {
+-  const char *hdr;
++  char *hdr;
+   int count, size;
+ 
+   struct response *resp = xnew0 (struct response);
+@@ -644,15 +644,23 @@ resp_new (const char *head)
+ break;
+ 
+   /* Find the end of HDR, including continuations. */
+-  do
++  for (;;)
+ {
+-  const char *end = strchr (hdr, '\n');
++  char *end = strchr (hdr, '\n');
++
+   if (end)
+ hdr = end + 1;
+   else
+ hdr += strlen (hdr);
++
++  if (*hdr != ' ' && *hdr != '\t')
++break;
++
++  // continuation, transform \r and \n into spaces
++  *end = ' ';
++  if (end > head && end[-1] == '\r')
++end[-1] = ' ';
+ }
+-  while (*hdr == ' ' || *hdr == '\t');
+ }
+   DO_REALLOC (resp->headers, size, count + 1, const char *);
+   resp->headers[count] = NULL;
+-- 
+2.13.3
+
diff --git a/meta/recipes-extended/wget/wget_1.19.1.bb 
b/meta/recipes-extended/wget/wget_1.19.1.bb
index 78bde95..3c484ce 100644
--- a/meta/recipes-extended/wget/wget_1.19.1.bb
+++ b/meta/recipes-extended/wget/wget_1.19.1.bb
@@ -1,6 +1,7 @@
 SRC_URI = "${GNU_MIRROR}/wget/wget-${PV}.tar.gz \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
file://CVE-2017-6508.patch \
+   file://0001-Fix-cookie-injection-CVE-2018-0494.patch \
   "
 
 SRC_URI[md5sum] = "87cea36b7161fd43e3fd51a4e8b89689"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 27/34] perl: CVE-2018-6797

[Jagadeesh Krishnanjanappa]

(perl #132227) restart a node if we change to uni rules within the node and 
encounter...
This could lead to a buffer overflow.

(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)

Affects perl >= 5.18 && perl <= 5.26

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/perl/perl/CVE-2018-6797.patch | 45 ++
 meta/recipes-devtools/perl/perl_5.24.1.bb  |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6797.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch
new file mode 100644
index 000..b56ebd3
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-6797.patch
@@ -0,0 +1,45 @@
+From abe1e6c568b96bcb382dfa4f61c56d1ab001ea51 Mon Sep 17 00:00:00 2001
+From: Karl Williamson 
+Date: Fri, 2 Feb 2018 15:14:27 -0700
+Subject: [PATCH] (perl #132227) restart a node if we change to uni rules
+ within the node and encounter a sharp S
+
+This could lead to a buffer overflow.
+
+(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)
+
+CVE: CVE-2018-6797
+Upstream-Status: Backport 
[https://perl5.git.perl.org/perl.git/commitdiff/abe1e6c568b96bcb382dfa4f61c56d1ab001ea51]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ regcomp.c | 12 
+ 1 file changed, 12 insertions(+)
+
+diff --git a/regcomp.c b/regcomp.c
+index 3b9550b10d..a7dee9a09e 100644
+--- a/regcomp.c
 b/regcomp.c
+@@ -13543,6 +13543,18 @@ S_regatom(pTHX_ RExC_state_t *pRExC_state, I32 
*flagp, U32 depth)
+  * /u.  This includes the multi-char fold SHARP S to
+  * 'ss' */
+ if (UNLIKELY(ender == LATIN_SMALL_LETTER_SHARP_S)) {
++
++/* If the node started out having uni rules, we
++ * wouldn't have gotten here.  So this means
++ * something in the middle has changed it, but
++ * didn't think it needed to reparse.  But this
++ * sharp s now does indicate the need for
++ * reparsing. */
++if (RExC_uni_semantics) {
++p = oldp;
++goto loopdone;
++}
++
+ RExC_seen_unfolded_sharp_s = 1;
+ maybe_exactfu = FALSE;
+ }
+-- 
+2.15.1-424-g9478a660812
+
+
diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb 
b/meta/recipes-devtools/perl/perl_5.24.1.bb
index e696910..dafd268 100644
--- a/meta/recipes-devtools/perl/perl_5.24.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
@@ -70,6 +70,7 @@ SRC_URI += " \
 file://CVE-2017-12837.patch \
 file://CVE-2018-6798-1.patch \
 file://CVE-2018-6798-2.patch \
+file://CVE-2018-6797.patch \
 "
 
 # Fix test case issues
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 25/34] qemu: CVE-2018-12617

[Jagadeesh Krishnanjanappa]

qga: check bytes count read by guest-file-read

While reading file content via 'guest-file-read' command,
'qmp_guest_file_read' routine allocates buffer of count+1
bytes. It could overflow for large values of 'count'.
Add check to avoid it.

Affects qemu < v3.0.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2018-12617.patch | 53 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch
new file mode 100644
index 000..c89f189
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2018-12617.patch
@@ -0,0 +1,53 @@
+From 141b197408ab398c4f474ac1a728ab316e921f2b Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Wed, 13 Jun 2018 11:46:57 +0530
+Subject: [PATCH] qga: check bytes count read by guest-file-read
+
+While reading file content via 'guest-file-read' command,
+'qmp_guest_file_read' routine allocates buffer of count+1
+bytes. It could overflow for large values of 'count'.
+Add check to avoid it.
+
+Reported-by: Fakhri Zulkifli 
+Signed-off-by: Prasad J Pandit 
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Michael Roth 
+
+CVE: CVE-2018-12617
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=141b197408ab398c4f474ac1a728ab316e921f2b]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ qga/commands-posix.c | 2 +-
+ qga/commands-win32.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/qga/commands-posix.c b/qga/commands-posix.c
+index 594d21ef3e..9284e71666 100644
+--- a/qga/commands-posix.c
 b/qga/commands-posix.c
+@@ -458,7 +458,7 @@ struct GuestFileRead *qmp_guest_file_read(int64_t handle, 
bool has_count,
+ 
+ if (!has_count) {
+ count = QGA_READ_COUNT_DEFAULT;
+-} else if (count < 0) {
++} else if (count < 0 || count >= UINT32_MAX) {
+ error_setg(errp, "value '%" PRId64 "' is invalid for argument count",
+count);
+ return NULL;
+diff --git a/qga/commands-win32.c b/qga/commands-win32.c
+index 70ee5379f6..73f31fa8c2 100644
+--- a/qga/commands-win32.c
 b/qga/commands-win32.c
+@@ -318,7 +318,7 @@ GuestFileRead *qmp_guest_file_read(int64_t handle, bool 
has_count,
+ }
+ if (!has_count) {
+ count = QGA_READ_COUNT_DEFAULT;
+-} else if (count < 0) {
++} else if (count < 0 || count >= UINT32_MAX) {
+ error_setg(errp, "value '%" PRId64
+"' is invalid for argument count", count);
+ return NULL;
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 5b88154..57d5106 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -34,6 +34,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://CVE-2017-15119.patch \
file://CVE-2017-18043.patch \
file://CVE-2018-7550.patch \
+   file://CVE-2018-12617.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 28/34] perl: CVE-2018-6913

[Jagadeesh Krishnanjanappa]

(perl #131844) fix various space calculation issues in
 pp_pack.c

- for the originally reported case, if the start/cur pointer is in the
  top 75% of the address space the add (cur) + glen addition would
  overflow, resulting in the condition failing incorrectly.

- the addition of the existing space used to the space needed could
  overflow, resulting in too small an allocation and a buffer overflow.

- the scaling for UTF8 could overflow.

- the multiply to calculate the space needed for many items could
  overflow.

For the first case, do a space calculation without making new pointers.

For the other cases, detect the overflow and croak if there's an
overflow.

Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.

For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.

Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.

One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.

Note: changed
plan tests => 14713;
to
plan tests => 14712;
in a/t/op/pack.t
to apply this patch on perl 5.24.1.

Affects perl < 5.26.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/perl/perl/CVE-2018-6913.patch | 153 +
 meta/recipes-devtools/perl/perl_5.24.1.bb  |   1 +
 2 files changed, 154 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-6913.patch

diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch 
b/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch
new file mode 100644
index 000..5df47dc
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-6913.patch
@@ -0,0 +1,153 @@
+From f17fed5006177dce8ac48229c424a2da0d6ba492 Mon Sep 17 00:00:00 2001
+From: Tony Cook 
+Date: Tue, 8 Aug 2017 09:32:58 +1000
+Subject: [PATCH] (perl #131844) fix various space calculation issues in
+ pp_pack.c
+
+- for the originally reported case, if the start/cur pointer is in the
+  top 75% of the address space the add (cur) + glen addition would
+  overflow, resulting in the condition failing incorrectly.
+
+- the addition of the existing space used to the space needed could
+  overflow, resulting in too small an allocation and a buffer overflow.
+
+- the scaling for UTF8 could overflow.
+
+- the multiply to calculate the space needed for many items could
+  overflow.
+
+For the first case, do a space calculation without making new pointers.
+
+For the other cases, detect the overflow and croak if there's an
+overflow.
+
+Originally this used Size_t_MAX as the maximum size of a memory
+allocation, but for -DDEBUGGING builds realloc() throws a panic for
+allocations over half the address space in size, changing the error
+reported for the allocation.
+
+For non-DEBUGGING builds the Size_t_MAX limit has the small chance
+of finding a system that has 3GB of contiguous space available, and
+allocating that space, which could be a denial of servce in some cases.
+
+Unfortunately changing the limit to half the address space means that
+the exact case with the original issue can no longer occur, so the
+test is no longer testing against the address + length issue that
+caused the original problem, since the allocation is failing earlier.
+
+One option would be to change the test so the size request by pack is
+just under 2GB, but this has a higher (but still low) probability that
+the system has the address space available, and will actually try to
+allocate the memory, so let's not do that.
+
+Note: changed 
+plan tests => 14713;
+to 
+plan tests => 14712;
+in a/t/op/pack.t
+to apply this patch on perl 5.24.1.
+
+CVE: CVE-2018-6913
+Upstream-Status: Backport 
[https://perl5.git.perl.org/perl.git/commitdiff/f17fed5006177dce8ac48229c424a2da0d6ba492]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ pp_pack.c   | 25 +
+ t/op/pack.t | 24 +++-
+ 2 files changed, 44 insertions(+), 5 deletions(-)
+
+diff --git a/pp_pack.c b/pp_pack.c
+index 8937d6d715..5e9cc64301 100644
+--- a/pp_pack.c
 b/pp_pack.c
+@@ -357,11 +357,28 @@ STMT_START { 
\
+ } \
+ } STMT_END
+ 
++#define SAFE_UTF8_EXPAND(var) \
++STMT_START {  \
++if ((var) > SSize_t_MAX / 

[OE-core] [ROCKO][PATCH V2 26/34] shadow: CVE-2018-7169

[Jagadeesh Krishnanjanappa]

newgidmap: enforce setgroups=deny if self-mapping a group

This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.

This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).

We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".

Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
Fixes: CVE-2018-7169

Affects shadow <= 4.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../shadow/files/CVE-2018-7169.patch   | 186 +
 meta/recipes-extended/shadow/shadow.inc|   1 +
 2 files changed, 187 insertions(+)
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2018-7169.patch

diff --git a/meta/recipes-extended/shadow/files/CVE-2018-7169.patch 
b/meta/recipes-extended/shadow/files/CVE-2018-7169.patch
new file mode 100644
index 000..36887d4
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2018-7169.patch
@@ -0,0 +1,186 @@
+From fb28c99b8a66ff2605c5cb96abc0a4d975f92de0 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai 
+Date: Thu, 15 Feb 2018 23:49:40 +1100
+Subject: [PATCH] newgidmap: enforce setgroups=deny if self-mapping a group
+
+This is necessary to match the kernel-side policy of "self-mapping in a
+user namespace is fine, but you cannot drop groups" -- a policy that was
+created in order to stop user namespaces from allowing trivial privilege
+escalation by dropping supplementary groups that were "blacklisted" from
+certain paths.
+
+This is the simplest fix for the underlying issue, and effectively makes
+it so that unless a user has a valid mapping set in /etc/subgid (which
+only administrators can modify) -- and they are currently trying to use
+that mapping -- then /proc/$pid/setgroups will be set to deny. This
+workaround is only partial, because ideally it should be possible to set
+an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
+administrators to further restrict newgidmap(1).
+
+We also don't write anything in the "allow" case because "allow" is the
+default, and users may have already written "deny" even if they
+technically are allowed to use setgroups. And we don't write anything if
+the setgroups policy is already "deny".
+
+Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
+Fixes: CVE-2018-7169
+
+Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/fb28c99b8a66ff2605c5cb96abc0a4d975f92de0]
+Reported-by: Craig Furman 
+Signed-off-by: Aleksa Sarai 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/newgidmap.c | 89 +++--
+ 1 file changed, 80 insertions(+), 9 deletions(-)
+
+diff --git a/src/newgidmap.c b/src/newgidmap.c
+index b1e33513..59a2e75c 100644
+--- a/src/newgidmap.c
 b/src/newgidmap.c
+@@ -46,32 +46,37 @@
+  */
+ const char *Prog;
+ 
+-static bool verify_range(struct passwd *pw, struct map_range *range)
++
++static bool verify_range(struct passwd *pw, struct map_range *range, bool 
*allow_setgroups)
+ {
+   /* An empty range is invalid */
+   if (range->count == 0)
+   return false;
+ 
+-  /* Test /etc/subgid */
+-  if (have_sub_gids(pw->pw_name, range->lower, range->count))
++  /* Test /etc/subgid. If the mapping is valid then we allow setgroups. */
++  if (have_sub_gids(pw->pw_name, range->lower, range->count)) {
++  *allow_setgroups = true;
+   return true;
++  }
+ 
+-  /* Allow a process to map it's own gid */
+-  if ((range->count == 1) && (pw->pw_gid == range->lower))
++  /* Allow a process to map its own gid. */
++  if ((range->count == 1) && (pw->pw_gid == range->lower)) {
++  /* noop -- if setgroups is enabled already we won't disable it. 
*/
+   return true;
++  }
+ 
+   return false;
+ }
+ 
+ static void verify_ranges(struct passwd *pw, int ranges,
+-  struct map_range *mappings)
++  struct map_range *mappings, bool *allow_setgroups)
+ {
+   struct map_range *mapping;
+   int idx;
+ 
+   mapping = mappings;
+   for (idx = 0; idx < ranges; idx++, mapping++) {
+-  if (!verify_range(pw, mapping)) {

[OE-core] [ROCKO][PATCH V2 23/34] qemu: CVE-2017-18043

[Jagadeesh Krishnanjanappa]

osdep: Fix ROUND_UP(64-bit, 32-bit)

When using bit-wise operations that exploit the power-of-two
nature of the second argument of ROUND_UP(), we still need to
ensure that the mask is as wide as the first argument (done
by using a ternary to force proper arithmetic promotion).
Unpatched, ROUND_UP(2ULL*1024*1024*1024*1024, 512U) produces 0,
instead of the intended 2TiB, because negation of an unsigned
32-bit quantity followed by widening to 64-bits does not
sign-extend the mask.

Broken since its introduction in commit 292c8e50 (v1.5.0).
Callers that passed the same width type to both macro parameters,
or that had other code to ensure the first parameter's maximum
runtime value did not exceed the second parameter's width, are
unaffected, but I did not audit to see which (if any) existing
clients of the macro could trigger incorrect behavior (I found
the bug while adding a new use of the macro).

While preparing the patch, checkpatch complained about poor
spacing, so I also fixed that here and in the nearby DIV_ROUND_UP.

Affects qemu < v2.11.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2017-18043.patch | 63 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch
new file mode 100644
index 000..955a24c
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2017-18043.patch
@@ -0,0 +1,63 @@
+From 2098b073f398cd628c09c5a78537a6854e85830d Mon Sep 17 00:00:00 2001
+From: Eric Blake 
+Date: Thu, 14 Sep 2017 08:49:23 -0500
+Subject: [PATCH] osdep: Fix ROUND_UP(64-bit, 32-bit)
+
+When using bit-wise operations that exploit the power-of-two
+nature of the second argument of ROUND_UP(), we still need to
+ensure that the mask is as wide as the first argument (done
+by using a ternary to force proper arithmetic promotion).
+Unpatched, ROUND_UP(2ULL*1024*1024*1024*1024, 512U) produces 0,
+instead of the intended 2TiB, because negation of an unsigned
+32-bit quantity followed by widening to 64-bits does not
+sign-extend the mask.
+
+Broken since its introduction in commit 292c8e50 (v1.5.0).
+Callers that passed the same width type to both macro parameters,
+or that had other code to ensure the first parameter's maximum
+runtime value did not exceed the second parameter's width, are
+unaffected, but I did not audit to see which (if any) existing
+clients of the macro could trigger incorrect behavior (I found
+the bug while adding a new use of the macro).
+
+While preparing the patch, checkpatch complained about poor
+spacing, so I also fixed that here and in the nearby DIV_ROUND_UP.
+
+CVE: CVE-2017-18043
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2098b073f398cd628c09c5a78537a6854]
+
+CC: qemu-triv...@nongnu.org
+CC: qemu-sta...@nongnu.org
+Signed-off-by: Eric Blake 
+Reviewed-by: Laszlo Ersek 
+Reviewed-by: Richard Henderson 
+Signed-off-by: Michael Tokarev 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ include/qemu/osdep.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
+index 72b75bf044..9dd318a7dd 100644
+--- a/include/qemu/osdep.h
 b/include/qemu/osdep.h
+@@ -205,13 +205,13 @@ extern int daemon(int, int);
+ 
+ /* Round number up to multiple. Requires that d be a power of 2 (see
+  * QEMU_ALIGN_UP for a safer but slower version on arbitrary
+- * numbers) */
++ * numbers); works even if d is a smaller type than n.  */
+ #ifndef ROUND_UP
+-#define ROUND_UP(n,d) (((n) + (d) - 1) & -(d))
++#define ROUND_UP(n, d) (((n) + (d) - 1) & -(0 ? (n) : (d)))
+ #endif
+ 
+ #ifndef DIV_ROUND_UP
+-#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
++#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
+ #endif
+ 
+ /*
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index a3cfb7c..48b8675 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -32,6 +32,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://memfd.patch \
file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
file://CVE-2017-15119.patch \
+   file://CVE-2017-18043.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 24/34] qemu: CVE-2018-7550

[Jagadeesh Krishnanjanappa]

multiboot: bss_end_addr can be zero

The multiboot spec
(https://www.gnu.org/software/grub/manual/multiboot/),
section 3.1.3, allows for bss_end_addr to be zero.

A zero bss_end_addr signifies there is no .bss section.

Affects qemu < v2.12.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-devtools/qemu/qemu/CVE-2018-7550.patch | 62 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch
new file mode 100644
index 000..9923d12
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2018-7550.patch
@@ -0,0 +1,62 @@
+From 2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8 Mon Sep 17 00:00:00 2001
+From: Jack Schwartz 
+Date: Thu, 21 Dec 2017 09:25:15 -0800
+Subject: [PATCH] multiboot: bss_end_addr can be zero
+
+The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/),
+section 3.1.3, allows for bss_end_addr to be zero.
+
+A zero bss_end_addr signifies there is no .bss section.
+
+CVE: CVE-2018-7550
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8]
+
+Suggested-by: Daniel Kiper 
+Signed-off-by: Jack Schwartz 
+Reviewed-by: Daniel Kiper 
+Reviewed-by: Prasad J Pandit 
+Signed-off-by: Kevin Wolf 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ hw/i386/multiboot.c | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
+index 46d9c68bf5..bb8d8e4629 100644
+--- a/hw/i386/multiboot.c
 b/hw/i386/multiboot.c
+@@ -233,12 +233,6 @@ int load_multiboot(FWCfgState *fw_cfg,
+ mh_entry_addr = ldl_p(header+i+28);
+ 
+ if (mh_load_end_addr) {
+-if (mh_bss_end_addr < mh_load_addr) {
+-fprintf(stderr, "invalid mh_bss_end_addr address\n");
+-exit(1);
+-}
+-mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+-
+ if (mh_load_end_addr < mh_load_addr) {
+ fprintf(stderr, "invalid mh_load_end_addr address\n");
+ exit(1);
+@@ -249,8 +243,16 @@ int load_multiboot(FWCfgState *fw_cfg,
+ fprintf(stderr, "invalid kernel_file_size\n");
+ exit(1);
+ }
+-mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+-mb_load_size = mb_kernel_size;
++mb_load_size = kernel_file_size - mb_kernel_text_offset;
++}
++if (mh_bss_end_addr) {
++if (mh_bss_end_addr < (mh_load_addr + mb_load_size)) {
++fprintf(stderr, "invalid mh_bss_end_addr address\n");
++exit(1);
++}
++mb_kernel_size = mh_bss_end_addr - mh_load_addr;
++} else {
++mb_kernel_size = mb_load_size;
+ }
+ 
+ /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 48b8675..5b88154 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -33,6 +33,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
file://CVE-2017-15119.patch \
file://CVE-2017-18043.patch \
+   file://CVE-2018-7550.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 22/34] libarchive: CVE-2017-14503

[Jagadeesh Krishnanjanappa]

Reject LHA archive entries with negative size.

Affects libarchive = 3.3.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libarchive/libarchive/CVE-2017-14503.patch | 33 ++
 .../libarchive/libarchive_3.3.2.bb |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch

diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
new file mode 100644
index 000..cbce50c
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2017-14503.patch
@@ -0,0 +1,33 @@
+From 2c8c83b9731ff822fad6cc8c670ea5519c366a14 Mon Sep 17 00:00:00 2001
+From: Joerg Sonnenberger 
+Date: Thu, 19 Jul 2018 21:14:53 +0200
+Subject: [PATCH] Reject LHA archive entries with negative size.
+
+Upstream-Status: Backport 
[https://github.com/libarchive/libarchive/commit/2c8c83b9731ff822fad6cc8c670ea5519c366a14]
+CVE: CVE-2017-14503
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ libarchive/archive_read_support_format_lha.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_lha.c 
b/libarchive/archive_read_support_format_lha.c
+index b8ef4ae1..95c99bb1 100644
+--- a/libarchive/archive_read_support_format_lha.c
 b/libarchive/archive_read_support_format_lha.c
+@@ -701,6 +701,12 @@ archive_read_format_lha_read_header(struct archive_read 
*a,
+* Prepare variables used to read a file content.
+*/
+   lha->entry_bytes_remaining = lha->compsize;
++  if (lha->entry_bytes_remaining < 0) {
++  archive_set_error(>archive,
++  ARCHIVE_ERRNO_FILE_FORMAT,
++  "Invalid LHa entry size");
++  return (ARCHIVE_FATAL);
++  }
+   lha->entry_offset = 0;
+   lha->entry_crc_calculated = 0;
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb 
b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
index 5daca27..3269716 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.3.2.bb
@@ -36,6 +36,7 @@ SRC_URI = 
"http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
file://CVE-2017-14166.patch \
file://CVE-2017-14502.patch \
file://non-recursive-extract-and-list.patch \
+   file://CVE-2017-14503.patch \
   "
 
 SRC_URI[md5sum] = "4583bd6b2ebf7e0e8963d90879eb1b27"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 18/34] pcmanfm: CVE-2017-8934

[Jagadeesh Krishnanjanappa]

Fix potential access violation, use runtime user dir instead of tmp dir.

pcmanfm = 1.2.5

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../recipes-sato/pcmanfm/files/CVE-2017-8934.patch | 60 ++
 meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb |  3 +-
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch

diff --git a/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch 
b/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch
new file mode 100644
index 000..ea34555
--- /dev/null
+++ b/meta/recipes-sato/pcmanfm/files/CVE-2017-8934.patch
@@ -0,0 +1,60 @@
+From bc8c3d871e9ecc67c47ff002b68cf049793faf08 Mon Sep 17 00:00:00 2001
+From: Andriy Grytsenko 
+Date: Sun, 14 May 2017 21:35:40 +0300
+Subject: [PATCH] Fix potential access violation, use runtime user dir instead
+ of tmp dir.
+
+CVE: CVE-2017-8934
+Upstream-Status: Backport 
[https://git.lxde.org/gitweb/?p=lxde/pcmanfm.git;a=commitdiff;h=bc8c3d871e9ecc67c47ff002b68cf049793faf08]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ NEWS  | 4 
+ src/single-inst.c | 7 ++-
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 8c2049a..876f7f3 100644
+--- a/NEWS
 b/NEWS
+@@ -1,3 +1,7 @@
++* Fixed potential access violation, use runtime user dir instead of tmp dir
++for single instance socket.
++
++
+ Changes on 1.2.5 since 1.2.4:
+ 
+ * Removed options to Cut, Remove and Rename from context menu on mounted
+diff --git a/src/single-inst.c b/src/single-inst.c
+index 62c37b3..aaf84ab 100644
+--- a/src/single-inst.c
 b/src/single-inst.c
+@@ -2,7 +2,7 @@
+  *  single-inst.c: simple IPC mechanism for single instance app
+  *
+  *  Copyright 2010 Hong Jen Yee (PCMan) 
+- *  Copyright 2012 Andriy Grytsenko (LStranger) 
++ *  Copyright 2012-2017 Andriy Grytsenko (LStranger) 
+  *
+  *  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
+@@ -404,11 +404,16 @@ static void get_socket_name(SingleInstData* data, char* 
buf, int len)
+ }
+ else
+ dpynum = 0;
++#if GLIB_CHECK_VERSION(2, 28, 0)
++g_snprintf(buf, len, "%s/%s-socket-%s-%d", g_get_user_runtime_dir(),
++   data->prog_name, host ? host : "", dpynum);
++#else
+ g_snprintf(buf, len, "%s/.%s-socket-%s-%d-%s",
+ g_get_tmp_dir(),
+ data->prog_name,
+ host ? host : "",
+ dpynum,
+ g_get_user_name());
++#endif
+ }
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
index 75ff773..0ab8a2e 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.5.bb
@@ -17,7 +17,8 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.xz 
\
   file://gnome-fs-regular.png \
   file://gnome-mime-text-plain.png \
   file://emblem-symbolic-link.png \
-  file://no-desktop.patch"
+  file://no-desktop.patch \
+  file://CVE-2017-8934.patch"
 
 SRC_URI[md5sum] = "b4d1f8ce08d87e4f27805a246fc51ac2"
 SRC_URI[sha256sum] = 
"0c86cac028b705ff314c7464d814c2cf7ff604c17491c20aa204b1ef1a80ad67"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 19/34] openssh: CVE-2017-15906

[Jagadeesh Krishnanjanappa]

disallow creation (of empty files) in read-only mode; reported by
Michal Zalewski, feedback & ok deraadt@

Affects openssh < 7.6

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../openssh/openssh/CVE-2017-15906.patch   | 38 ++
 meta/recipes-connectivity/openssh/openssh_7.5p1.bb |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch

diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch 
b/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch
new file mode 100644
index 000..3ad683d
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/CVE-2017-15906.patch
@@ -0,0 +1,38 @@
+From a6981567e8e215acc1ef690c8dbb30f2d9b00a19 Mon Sep 17 00:00:00 2001
+From: djm 
+Date: Tue, 4 Apr 2017 00:24:56 +
+Subject: [PATCH] disallow creation (of empty files) in read-only mode;
+ reported by Michal Zalewski, feedback & ok deraadt@
+
+CVE: CVE-2017-15906
+Upstream-Status: Backport 
[https://github.com/openbsd/src/commit/a6981567e8e215acc1ef690c8dbb30f2d9b00a19]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ usr.bin/ssh/sftp-server.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/usr.bin/ssh/sftp-server.c b/usr.bin/ssh/sftp-server.c
+index 2510d234a3a..42249ebd60d 100644
+--- a/usr.bin/ssh/sftp-server.c
 b/usr.bin/ssh/sftp-server.c
+@@ -1,4 +1,4 @@
+-/* $OpenBSD: sftp-server.c,v 1.110 2016/09/12 01:22:38 deraadt Exp $ */
++/* $OpenBSD: sftp-server.c,v 1.111 2017/04/04 00:24:56 djm Exp $ */
+ /*
+  * Copyright (c) 2000-2004 Markus Friedl.  All rights reserved.
+  *
+@@ -683,8 +683,8 @@ process_open(u_int32_t id)
+   logit("open \"%s\" flags %s mode 0%o",
+   name, string_from_portable(pflags), mode);
+   if (readonly &&
+-  ((flags & O_ACCMODE) == O_WRONLY ||
+-  (flags & O_ACCMODE) == O_RDWR)) {
++  ((flags & O_ACCMODE) != O_RDONLY ||
++  (flags & (O_CREAT|O_TRUNC)) != 0)) {
+   verbose("Refusing open request in read-only mode");
+   status = SSH2_FX_PERMISSION_DENIED;
+   } else {
+-- 
+2.13.3
+
diff --git a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
index 86ca6ff..395c21b 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
@@ -28,6 +28,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://0001-openssh-Fix-syntax-error-on-x32.patch \
file://sshd_check_keys \
+   file://CVE-2017-15906.patch;striplevel=3 \
"
 
 PAM_SRC_URI = "file://sshd"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 16/34] Qemu CVE-2018-11806 slirp-heap-buffer-overflow

[Jagadeesh Krishnanjanappa]

From: Jeremy Puhlman 

slirp: correct size computation while concatenating mbuf

While reassembling incoming fragmented datagrams, 'm_cat' routine
extends the 'mbuf' buffer, if it has insufficient room. It computes
a wrong buffer size, which leads to overwriting adjacent heap buffer
area. Correct this size computation in m_cat.

Affects qemu < 3.0.0

Signed-off-by: Jeremy Puhlman 
---
 ...018-11806-QEMU-slirp-heap-buffer-overflow.patch | 71 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch

diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
new file mode 100644
index 000..f09b0bf
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
@@ -0,0 +1,71 @@
+From dc21a9d2951f0a2a7e63633e2b5c68c54e4edc4b Mon Sep 17 00:00:00 2001
+From: Jeremy Puhlman 
+Date: Thu, 14 Jun 2018 01:28:49 +
+Subject: [PATCH] CVE-2018-11806 QEMU: slirp: heap buffer overflow
+
+Subject: [Qemu-devel] [PATCH 1/2] slirp: correct size computation while 
concatenating mbuf
+Date:  Tue, 5 Jun 2018 23:38:35 +0530
+From: Prasad J Pandit 
+
+While reassembling incoming fragmented datagrams, 'm_cat' routine
+extends the 'mbuf' buffer, if it has insufficient room. It computes
+a wrong buffer size, which leads to overwriting adjacent heap buffer
+area. Correct this size computation in m_cat.
+
+Reported-by: ZDI Disclosures 
+Signed-off-by: Prasad J Pandit 
+
+CVE: CVE-2018-11806
+Upstream-status: Backport 
[https://github.com/qemu/qemu/commit/864036e251f54c99d31df124aad7f34f01f5344c#diff-de3b23fd63b9e35d35c454525498d51c]
+
+https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html
+
+---
+ slirp/mbuf.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+Signed-off-by: Jeremy Puhlman 
+---
+ slirp/mbuf.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/slirp/mbuf.c b/slirp/mbuf.c
+index 5ff2455..7fb4501 100644
+--- a/slirp/mbuf.c
 b/slirp/mbuf.c
+@@ -138,7 +138,7 @@ m_cat(struct mbuf *m, struct mbuf *n)
+* If there's no room, realloc
+*/
+   if (M_FREEROOM(m) < n->m_len)
+-  m_inc(m,m->m_size+MINCSIZE);
++   m_inc(m, m->m_len + n->m_len);
+ 
+   memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
+   m->m_len += n->m_len;
+@@ -158,12 +158,12 @@ m_inc(struct mbuf *m, int size)
+ 
+ if (m->m_flags & M_EXT) {
+ datasize = m->m_data - m->m_ext;
+-  m->m_ext = g_realloc(m->m_ext, size);
++  m->m_ext = g_realloc(m->m_ext, size + datasize);
+ m->m_data = m->m_ext + datasize;
+ } else {
+ char *dat;
+ datasize = m->m_data - m->m_dat;
+-  dat = g_malloc(size);
++  dat = g_malloc(size + datasize);
+ memcpy(dat, m->m_dat, m->m_size);
+ 
+ m->m_ext = dat;
+@@ -171,7 +171,7 @@ m_inc(struct mbuf *m, int size)
+ m->m_flags |= M_EXT;
+ }
+ 
+-m->m_size = size;
++m->m_size = size + datasize;
+ 
+ }
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index bdf6c21..89c68f2 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -30,6 +30,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://CVE-2017-14167.patch \
file://ppc_locking.patch \
file://memfd.patch \
+   file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 15/34] curl: CVE-2018-0500

[Jagadeesh Krishnanjanappa]

smtp: use the upload buffer size for scratch buffer malloc

... not the read buffer size, as that can be set smaller and thus cause
a buffer overflow! CVE-2018-0500

Reported-by: Peter Wu
Bug: https://curl.haxx.se/docs/adv_2018-70a2.html

Affects curl >= 7.54.1 && curl <= 7.60.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta/recipes-support/curl/curl/CVE-2018-0500.patch | 39 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-0500.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-0500.patch 
b/meta/recipes-support/curl/curl/CVE-2018-0500.patch
new file mode 100644
index 000..4395a3c
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-0500.patch
@@ -0,0 +1,39 @@
+From ba1dbd78e5f1ed67c1b8d37ac89d90e5e330b628 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Wed, 13 Jun 2018 12:24:40 +0200
+Subject: [PATCH] smtp: use the upload buffer size for scratch buffer malloc
+
+... not the read buffer size, as that can be set smaller and thus cause
+a buffer overflow! CVE-2018-0500
+
+Reported-by: Peter Wu
+Bug: https://curl.haxx.se/docs/adv_2018-70a2.html
+
+CVE: CVE-2018-0500
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/ba1dbd78e5f1e.patch]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/smtp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/lib/smtp.c b/lib/smtp.c
+index e6872badb8..ecf10a41ac 100644
+--- a/lib/smtp.c
 b/lib/smtp.c
+@@ -1563,13 +1563,14 @@ CURLcode Curl_smtp_escape_eob(struct connectdata 
*conn, const ssize_t nread)
+   if(!scratch || data->set.crlf) {
+ oldscratch = scratch;
+ 
+-scratch = newscratch = malloc(2 * data->set.buffer_size);
++scratch = newscratch = malloc(2 * UPLOAD_BUFSIZE);
+ if(!newscratch) {
+   failf(data, "Failed to alloc scratch buffer!");
+ 
+   return CURLE_OUT_OF_MEMORY;
+ }
+   }
++  DEBUGASSERT(UPLOAD_BUFSIZE >= nread);
+ 
+   /* Have we already sent part of the EOB? */
+   eob_sent = smtp->eob;
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index 4376bb3..7dc5381 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -9,6 +9,7 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
file://CVE-2018-1000300.patch \
file://CVE-2018-1000301.patch \
+   file://CVE-2018-0500.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 21/34] libsndfile1: CVE-2017-14634

[Jagadeesh Krishnanjanappa]

double64_init: Check psf->sf.channels against upper bound

This prevents division by zero later in the code.

While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.

CVE-2017-14634

Closes: #318

Affects libsndfile1 = 1.0.28

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../libsndfile/libsndfile1/CVE-2017-14634.patch| 42 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
new file mode 100644
index 000..39b4ec1
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14634.patch
@@ -0,0 +1,42 @@
+From 85c877d5072866aadbe8ed0c3e0590fbb5e16788 Mon Sep 17 00:00:00 2001
+From: Fabian Greffrath 
+Date: Thu, 28 Sep 2017 12:15:04 +0200
+Subject: [PATCH] double64_init: Check psf->sf.channels against upper bound
+
+This prevents division by zero later in the code.
+
+While the trivial case to catch this (i.e. sf.channels < 1) has already
+been covered, a crafted file may report a number of channels that is
+so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
+miscalculated to zero (if this makes sense) in the determination of the
+blockwidth. Since we only support a limited number of channels anyway,
+make sure to check here as well.
+
+CVE: CVE-2017-14634
+
+Closes: https://github.com/erikd/libsndfile/issues/318
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/85c877d5072866aadbe8ed0c3e0590fbb5e16788]
+
+Signed-off-by: Erik de Castro Lopo 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ src/double64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/double64.c b/src/double64.c
+index b318ea8..78dfef7 100644
+--- a/src/double64.c
 b/src/double64.c
+@@ -91,7 +91,7 @@ int
+ double64_init (SF_PRIVATE *psf)
+ { static int double64_caps ;
+ 
+-  if (psf->sf.channels < 1)
++  if (psf->sf.channels < 1 || psf->sf.channels > SF_MAX_CHANNELS)
+   {   psf_log_printf (psf, "double64_init : internal error : channels 
= %d\n", psf->sf.channels) ;
+   return SFE_INTERNAL ;
+   } ;
+-- 
+2.13.3
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index c6f2a46..ed43b74 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2017-8362.patch \
file://CVE-2017-8363.patch \
file://CVE-2017-14245-14246.patch \
+   file://CVE-2017-14634.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 20/34] git: CVE-2017-15298

[Jagadeesh Krishnanjanappa]

revision: quit pruning diff more quickly when possible
When the revision traversal machinery is given a pathspec,
we must compute the parent-diff for each commit to determine
which ones are TREESAME. We set the QUICK diff flag to avoid
looking at more entries than we need; we really just care
whether there are any changes at all.

But there is one case where we want to know a bit more: if
--remove-empty is set, we care about finding cases where the
change consists only of added entries (in which case we may
prune the parent in try_to_simplify_commit()). To cover that
case, our file_add_remove() callback does not quit the diff
upon seeing an added entry; it keeps looking for other types
of entries.

But this means when --remove-empty is not set (and it is not
by default), we compute more of the diff than is necessary.
You can see this in a pathological case where a commit adds
a very large number of entries, and we limit based on a
broad pathspec. E.g.:

  perl -e '
chomp(my $blob = `git hash-object -w --stdin remove_empty_trees. This callback parameter could be
passed to the "add_remove" and "change" callbacks, but
there's not much point. They already receive the
diff_options struct, and doing it this way avoids having to
update the function signature of the other callbacks
(arguably the format_callback and output_prefix functions
could benefit from the same simplification).

Affects git <= 2.14.2

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../git/files/CVE-2017-15298.patch | 132 +
 meta/recipes-devtools/git/git.inc  |   3 +-
 2 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/files/CVE-2017-15298.patch

diff --git a/meta/recipes-devtools/git/files/CVE-2017-15298.patch 
b/meta/recipes-devtools/git/files/CVE-2017-15298.patch
new file mode 100644
index 000..0d349dd
--- /dev/null
+++ b/meta/recipes-devtools/git/files/CVE-2017-15298.patch
@@ -0,0 +1,132 @@
+From a937b37e766479c8e780b17cce9c4b252fd97e40 Mon Sep 17 00:00:00 2001
+From: Jeff King 
+Date: Fri, 13 Oct 2017 11:27:45 -0400
+Subject: revision: quit pruning diff more quickly when possible
+
+When the revision traversal machinery is given a pathspec,
+we must compute the parent-diff for each commit to determine
+which ones are TREESAME. We set the QUICK diff flag to avoid
+looking at more entries than we need; we really just care
+whether there are any changes at all.
+
+But there is one case where we want to know a bit more: if
+--remove-empty is set, we care about finding cases where the
+change consists only of added entries (in which case we may
+prune the parent in try_to_simplify_commit()). To cover that
+case, our file_add_remove() callback does not quit the diff
+upon seeing an added entry; it keeps looking for other types
+of entries.
+
+But this means when --remove-empty is not set (and it is not
+by default), we compute more of the diff than is necessary.
+You can see this in a pathological case where a commit adds
+a very large number of entries, and we limit based on a
+broad pathspec. E.g.:
+
+  perl -e '
+chomp(my $blob = `git hash-object -w --stdin remove_empty_trees. This callback parameter could be
+passed to the "add_remove" and "change" callbacks, but
+there's not much point. They already receive the
+diff_options struct, and doing it this way avoids having to
+update the function signature of the other callbacks
+(arguably the format_callback and output_prefix functions
+could benefit from the same simplification).
+
+CVE: CVE-2017-15298
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/git/git.git/commit/?id=a937b37e76]
+
+Signed-off-by: Jeff King 
+Signed-off-by: Junio C Hamano 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ diff.h |  1 +
+ revision.c | 16 +---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/diff.h b/diff.h
+index e9ccb38c26..fe5c287a70 100644
+--- a/diff.h
 b/diff.h
+@@ -180,6 +180,7 @@ struct diff_options {
+   pathchange_fn_t pathchange;
+   change_fn_t change;
+   add_remove_fn_t add_remove;
++  void *change_fn_data;
+   diff_format_fn_t format_callback;
+   void *format_callback_data;
+   diff_prefix_fn_t output_prefix;
+diff --git a/revision.c b/revision.c
+index 771d079f6e..7c23ab7afe 100644
+--- a/revision.c
 b/revision.c
+@@ -394,8 +394,16 @@ static struct commit *one_relevant_parent(const struct 
rev_info *revs,
+  * if the whole diff is removal of old data, and otherwise
+  * REV_TREE_DIFFERENT (of course if the trees are the same we
+  * want REV_TREE_SAME).
+- * That means that once we get to REV_TREE_DIFFERENT, we do not
+- * have to look any further.
++ *
++ * The only time we care about the distinction is when
++ * remove_empty_trees is in effect, in which case we care only about
++ * whether the whole change is REV_TREE_NEW, or if there's another type
++ * of change. Which means we can stop the diff 

[OE-core] [ROCKO][PATCH V2 11/34] curl: CVE-2018-1000300

[Jagadeesh Krishnanjanappa]

pingpong: fix response cache memcpy overflow

Response data for a handle with a large buffer might be cached and then
used with the "closure" handle when it has a smaller buffer and then
he
larger cache will be copied and overflow the new smaller heap based
buffer.

Reported-by: Dario Weisser
CVE: CVE-2018-1000300
Bug: https://curl.haxx.se/docs/adv_2018-82c2.html

Affects curl >= 7.54.1 && curl <= 7.59.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../curl/curl/CVE-2018-1000300.patch   | 44 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-1000300.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-1000300.patch 
b/meta/recipes-support/curl/curl/CVE-2018-1000300.patch
new file mode 100644
index 000..893d45c
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-1000300.patch
@@ -0,0 +1,44 @@
+From 0a79d714bd55779a3a223efb5c089d0ad7e128a8 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Fri, 23 Mar 2018 23:30:04 +0100
+Subject: [PATCH] pingpong: fix response cache memcpy overflow
+
+Response data for a handle with a large buffer might be cached and then
+used with the "closure" handle when it has a smaller buffer and then the
+larger cache will be copied and overflow the new smaller heap based
+buffer.
+
+Reported-by: Dario Weisser
+
+CVE: CVE-2018-1000300
+Bug: https://curl.haxx.se/docs/adv_2018-82c2.html
+Upstream-Status: Backport 
[https://github.com/curl/curl-www/commit/3ee30b2b5e3836345ac510bc1674aa3a4272936e]
+
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/pingpong.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/lib/pingpong.c b/lib/pingpong.c
+index 438856a99..ad370ee82 100644
+--- a/lib/pingpong.c
 b/lib/pingpong.c
+@@ -302,11 +302,14 @@ CURLcode Curl_pp_readresp(curl_socket_t sockfd,
+*
+* pp->cache_size is cast to ssize_t here.  This should be safe, because
+* it would have been populated with something of size int to begin
+* with, even though its datatype may be larger than an int.
+*/
+-  DEBUGASSERT((ptr + pp->cache_size) <= (buf + data->set.buffer_size + 
1));
++  if((ptr + pp->cache_size) > (buf + data->set.buffer_size + 1)) {
++failf(data, "cached response data too big to handle");
++return CURLE_RECV_ERROR;
++  }
+   memcpy(ptr, pp->cache, pp->cache_size);
+   gotbytes = (ssize_t)pp->cache_size;
+   free(pp->cache);/* free the cache */
+   pp->cache = NULL;   /* clear the pointer */
+   pp->cache_size = 0; /* zero the size just in case */
+-- 
+2.17.0
+
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index d2d0180..fdfbb3d 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
+   file://CVE-2018-1000300.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [ROCKO][PATCH V2 17/34] qemu: CVE-2017-15119

[Jagadeesh Krishnanjanappa]

nbd/server: CVE-2017-15119 Reject options larger than 32M

The NBD spec gives us permission to abruptly disconnect on clients
that send outrageously large option requests, rather than having
to spend the time reading to the end of the option.  No real
option request requires that much data anyways; and meanwhile, we
already have the practice of abruptly dropping the connection on
any client that sends NBD_CMD_WRITE with a payload larger than 32M.

For comparison, nbdkit drops the connection on any request with
more than 4096 bytes; however, that limit is probably too low
(as the NBD spec states an export name can theoretically be up
to 4096 bytes, which means a valid NBD_OPT_INFO could be even
longer) - even if qemu doesn't permit exports longer than 256
bytes.

It could be argued that a malicious client trying to get us to
read nearly 4G of data on a bad request is a form of denial of
service.  In particular, if the server requires TLS, but a client
that does not know the TLS credentials sends any option (other
than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
payload of nearly 4G, then the server was keeping the connection
alive trying to read all the payload, tying up resources that it
would rather be spending on a client that can get past the TLS
handshake.  Hence, this warranted a CVE.

Present since at least 2.5 when handling known options, and made
worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
to handle unknown options.

Affects qemu < 2.11

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../qemu/qemu/CVE-2017-15119.patch | 63 ++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
new file mode 100644
index 000..10da519
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
@@ -0,0 +1,63 @@
+From fdad35ef6c5839d50dfc14073364ac893afebc30 Mon Sep 17 00:00:00 2001
+From: Eric Blake 
+Date: Wed, 22 Nov 2017 16:25:16 -0600
+Subject: [PATCH] nbd/server: CVE-2017-15119 Reject options larger than 32M
+
+The NBD spec gives us permission to abruptly disconnect on clients
+that send outrageously large option requests, rather than having
+to spend the time reading to the end of the option.  No real
+option request requires that much data anyways; and meanwhile, we
+already have the practice of abruptly dropping the connection on
+any client that sends NBD_CMD_WRITE with a payload larger than 32M.
+
+For comparison, nbdkit drops the connection on any request with
+more than 4096 bytes; however, that limit is probably too low
+(as the NBD spec states an export name can theoretically be up
+to 4096 bytes, which means a valid NBD_OPT_INFO could be even
+longer) - even if qemu doesn't permit exports longer than 256
+bytes.
+
+It could be argued that a malicious client trying to get us to
+read nearly 4G of data on a bad request is a form of denial of
+service.  In particular, if the server requires TLS, but a client
+that does not know the TLS credentials sends any option (other
+than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
+payload of nearly 4G, then the server was keeping the connection
+alive trying to read all the payload, tying up resources that it
+would rather be spending on a client that can get past the TLS
+handshake.  Hence, this warranted a CVE.
+
+Present since at least 2.5 when handling known options, and made
+worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
+to handle unknown options.
+
+CC: qemu-sta...@nongnu.org
+CVE: CVE-2017-15119
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commit;h=fdad35ef6c5839d50dfc14073364ac893afebc30]
+
+Signed-off-by: Eric Blake 
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ nbd/server.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/nbd/server.c b/nbd/server.c
+index 7d6801b427..a81801e3bc 100644
+--- a/nbd/server.c
 b/nbd/server.c
+@@ -673,6 +673,12 @@ static int nbd_negotiate_options(NBDClient *client, 
uint16_t myflags,
+ }
+ length = be32_to_cpu(length);
+ 
++if (length > NBD_MAX_BUFFER_SIZE) {
++error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u)",
++   length, NBD_MAX_BUFFER_SIZE);
++return -EINVAL;
++}
++
+ trace_nbd_negotiate_options_check_option(option,
+  nbd_opt_lookup(option));
+ if (client->tlscreds &&
+-- 
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 89c68f2..a3cfb7c 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -31,6 +31,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
  

[OE-core] [ROCKO][PATCH V2 12/34] curl: CVE-2018-1000301

[Jagadeesh Krishnanjanappa]

http: restore buffer pointer when bad response-line is parsed

... leaving the k->str could lead to buffer over-reads later on.

CVE: CVE-2018-1000301
Assisted-by: Max Dymond

Detected by OSS-Fuzz.
Bug: https://curl.haxx.se/docs/adv_2018-b138.html
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105

Affects curl >= 7.20.0 && curl <= 7.59.0

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 .../curl/curl/CVE-2018-1000301.patch   | 54 ++
 meta/recipes-support/curl/curl_7.58.0.bb   |  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-1000301.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-1000301.patch 
b/meta/recipes-support/curl/curl/CVE-2018-1000301.patch
new file mode 100644
index 000..f42178e
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-1000301.patch
@@ -0,0 +1,54 @@
+From 8c7b3737d29ed5c0575bf592063de8a51450812d Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Sat, 24 Mar 2018 23:47:41 +0100
+Subject: [PATCH] http: restore buffer pointer when bad response-line is parsed
+
+... leaving the k->str could lead to buffer over-reads later on.
+
+CVE: CVE-2018-1000301
+Assisted-by: Max Dymond
+
+Detected by OSS-Fuzz.
+Bug: https://curl.haxx.se/docs/adv_2018-b138.html
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105
+
+Upstream-Status: Backport 
[https://github.com/curl/curl-www/commit/3ee30b2b5e3836345ac510bc1674aa3a4272936e]
+Signed-off-by: Jagadeesh Krishnanjanappa 
+---
+ lib/http.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/lib/http.c b/lib/http.c
+index 1a313b4fb..e080ae513 100644
+--- a/lib/http.c
 b/lib/http.c
+@@ -3012,10 +3012,12 @@ CURLcode Curl_http_readwrite_headers(struct Curl_easy 
*data,
+ssize_t *nread,
+bool *stop_reading)
+ {
+   CURLcode result;
+   struct SingleRequest *k = >req;
++  ssize_t onread = *nread;
++  char *ostr = k->str;
+ 
+   /* header line within buffer loop */
+   do {
+ size_t rest_length;
+ size_t full_length;
+@@ -3076,11 +3078,13 @@ CURLcode Curl_http_readwrite_headers(struct Curl_easy 
*data,
+   /* since there's more, this is a partial bad header */
+   k->badheader = HEADER_PARTHEADER;
+ else {
+   /* this was all we read so it's all a bad header */
+   k->badheader = HEADER_ALLBAD;
+-  *nread = (ssize_t)rest_length;
++  *nread = onread;
++  k->str = ostr;
++  return CURLE_OK;
+ }
+ break;
+   }
+ }
+ 
+-- 
+2.17.0
diff --git a/meta/recipes-support/curl/curl_7.58.0.bb 
b/meta/recipes-support/curl/curl_7.58.0.bb
index fdfbb3d..4376bb3 100644
--- a/meta/recipes-support/curl/curl_7.58.0.bb
+++ b/meta/recipes-support/curl/curl_7.58.0.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
file://CVE-2018-1000300.patch \
+   file://CVE-2018-1000301.patch \
 "
 
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core