[OE-core][dunfell][PATCH] ncurses: Backport fix for CVE-2023-50495

2024-04-02 Thread Vijay Anusuri via lists.openembedded.org
From: Vijay Anusuri 

Upstream-Status: Backport from 
https://github.com/ThomasDickey/ncurses-snapshots/commit/efe9674ee14b14b788f9618941f97d31742f0adc

Reference: 
https://invisible-island.net/archives/ncurses/6.4/ncurses-6.4-20230424.patch.gz

Signed-off-by: Vijay Anusuri 
---
 .../ncurses/files/CVE-2023-50495.patch| 79 +++
 meta/recipes-core/ncurses/ncurses_6.2.bb  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 meta/recipes-core/ncurses/files/CVE-2023-50495.patch

diff --git a/meta/recipes-core/ncurses/files/CVE-2023-50495.patch 
b/meta/recipes-core/ncurses/files/CVE-2023-50495.patch
new file mode 100644
index 00..58c23866d1
--- /dev/null
+++ b/meta/recipes-core/ncurses/files/CVE-2023-50495.patch
@@ -0,0 +1,79 @@
+Fix for CVE-2023-50495 from upstream:
+https://github.com/ThomasDickey/ncurses-snapshots/commit/efe9674ee14b14b788f9618941f97d31742f0adc
+
+Reference:
+https://invisible-island.net/archives/ncurses/6.4/ncurses-6.4-20230424.patch.gz
+
+Upstream-Status: Backport [import from suse 
ftp.pbone.net/mirror/ftp.opensuse.org/update/leap-micro/5.3/sle/src/ncurses-6.1-15.5.20.1.src.rpm
+Upstream commit 
https://github.com/ThomasDickey/ncurses-snapshots/commit/efe9674ee14b14b788f9618941f97d31742f0adc]
+CVE: CVE-2023-50495
+Signed-off-by: Vijay Anusuri 
+---
+ ncurses/tinfo/parse_entry.c | 23 ---
+ 1 file changed, 16 insertions(+), 7 deletions(-)
+
+diff --git a/ncurses/tinfo/parse_entry.c b/ncurses/tinfo/parse_entry.c
+index 23574b66..56ba9ae6 100644
+--- a/ncurses/tinfo/parse_entry.c
 b/ncurses/tinfo/parse_entry.c
+@@ -110,7 +110,7 @@ _nc_extend_names(ENTRY * entryp, const char *name, int 
token_type)
+   /* Well, we are given a cancel for a name that we don't recognize */
+   return _nc_extend_names(entryp, name, STRING);
+ default:
+-  return 0;
++  return NULL;
+ }
+ 
+ /* Adjust the 'offset' (insertion-point) to keep the lists of extended
+@@ -142,6 +142,11 @@ _nc_extend_names(ENTRY * entryp, const char *name, int 
token_type)
+   for (last = (unsigned) (max - 1); last > tindex; last--)
+ 
+ if (!found) {
++  char *saved;
++
++  if ((saved = _nc_save_str(name)) == NULL)
++  return NULL;
++
+   switch (token_type) {
+   case BOOLEAN:
+   tp->ext_Booleans++;
+@@ -169,7 +174,7 @@ _nc_extend_names(ENTRY * entryp, const char *name, int 
token_type)
+   TYPE_REALLOC(char *, actual, tp->ext_Names);
+   while (--actual > offset)
+   tp->ext_Names[actual] = tp->ext_Names[actual - 1];
+-  tp->ext_Names[offset] = _nc_save_str(name);
++  tp->ext_Names[offset] = saved;
+ }
+ 
+ temp.nte_name = tp->ext_Names[offset];
+@@ -337,6 +342,8 @@ _nc_parse_entry(ENTRY * entryp, int literal, bool silent)
+   bool is_use = (strcmp(_nc_curr_token.tk_name, "use") == 0);
+   bool is_tc = !is_use && (strcmp(_nc_curr_token.tk_name, "tc") == 0);
+   if (is_use || is_tc) {
++  char *saved;
++
+   if (!VALID_STRING(_nc_curr_token.tk_valstring)
+   || _nc_curr_token.tk_valstring[0] == '\0') {
+   _nc_warning("missing name for use-clause");
+@@ -350,11 +357,13 @@ _nc_parse_entry(ENTRY * entryp, int literal, bool silent)
+   _nc_curr_token.tk_valstring);
+   continue;
+   }
+-  entryp->uses[entryp->nuses].name = 
_nc_save_str(_nc_curr_token.tk_valstring);
+-  entryp->uses[entryp->nuses].line = _nc_curr_line;
+-  entryp->nuses++;
+-  if (entryp->nuses > 1 && is_tc) {
+-  BAD_TC_USAGE
++  if ((saved = _nc_save_str(_nc_curr_token.tk_valstring)) != NULL) {
++  entryp->uses[entryp->nuses].name = saved;
++  entryp->uses[entryp->nuses].line = _nc_curr_line;
++  entryp->nuses++;
++  if (entryp->nuses > 1 && is_tc) {
++  BAD_TC_USAGE
++  }
+   }
+   } else {
+   /* normal token lookup */
+-- 
+2.25.1
+
diff --git a/meta/recipes-core/ncurses/ncurses_6.2.bb 
b/meta/recipes-core/ncurses/ncurses_6.2.bb
index 33285bcb5b..dbff149f55 100644
--- a/meta/recipes-core/ncurses/ncurses_6.2.bb
+++ b/meta/recipes-core/ncurses/ncurses_6.2.bb
@@ -6,6 +6,7 @@ SRC_URI += "file://0001-tic-hang.patch \
file://CVE-2021-39537.patch \
file://CVE-2022-29458.patch \
file://CVE-2023-29491.patch \
+   file://CVE-2023-50495.patch \
"
 # commit id corresponds to the revision in package version
 SRCREV = "a669013cd5e9d6434e5301348ea51baf306c93c4"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197903): 
https://lists.openembedded.org/g/openembedded-core/message/197903
Mute This Topic: https://lists.openembedded.org/mt/105303486/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 

[OE-core][kirkstone 9/9] common-licenses: Backport missing license

2024-04-02 Thread Steve Sakoman
From: Colin McAllister 

Backports missing license from master to kirkstone.

Signed-off-by: Colin McAllister 
Signed-off-by: Steve Sakoman 
---
 .../LGPL-3.0-with-zeromq-exception| 181 ++
 1 file changed, 181 insertions(+)
 create mode 100644 meta/files/common-licenses/LGPL-3.0-with-zeromq-exception

diff --git a/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception 
b/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception
new file mode 100644
index 00..02e943c4ac
--- /dev/null
+++ b/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception
@@ -0,0 +1,181 @@
+GNU LESSER GENERAL PUBLIC LICENSE
+   Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. 
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+  This version of the GNU Lesser General Public License incorporates
+the terms and conditions of version 3 of the GNU General Public
+License, supplemented by the additional permissions listed below.
+
+  0. Additional Definitions. 
+
+  As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the GNU
+General Public License.
+
+  "The Library" refers to a covered work governed by this License,
+other than an Application or a Combined Work as defined below.
+
+  An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+  A "Combined Work" is a work produced by combining or linking an
+Application with the Library.  The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+  The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+  The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+  1. Exception to Section 3 of the GNU GPL.
+
+  You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+  2. Conveying Modified Versions.
+
+  If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+   a) under this License, provided that you make a good faith effort to
+   ensure that, in the event an Application does not supply the
+   function or data, the facility still operates, and performs
+   whatever part of its purpose remains meaningful, or
+
+   b) under the GNU GPL, with none of the additional permissions of
+   this License applicable to that copy.
+
+  3. Object Code Incorporating Material from Library Header Files.
+
+  The object code form of an Application may incorporate material from
+a header file that is part of the Library.  You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+   a) Give prominent notice with each copy of the object code that the
+   Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the object code with a copy of the GNU GPL and this license
+   document.
+
+  4. Combined Works.
+
+  You may convey a Combined Work under terms of your choice that,
+taken together, effectively do not restrict modification of the
+portions of the Library contained in the Combined Work and reverse
+engineering for debugging such modifications, if you also do each of
+the following:
+
+   a) Give prominent notice with each copy of the Combined Work that
+   the Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the Combined Work with a copy of the GNU GPL and this license
+   document.
+
+   c) For a Combined Work that displays copyright notices during
+   execution, include the copyright notice for the Library among
+   these notices, as well as a reference directing the user to the
+   copies of the GNU GPL and this license document.
+
+   d) Do one of the following:
+
+   0) Convey the Minimal 

[OE-core][kirkstone 8/9] gcc: Backport sanitizer fix for 32-bit ALSR

2024-04-02 Thread Steve Sakoman
From: Claus Stovgaard 

When using the gcc-sanitizers as part of the SDK on a Linux with a newer
kernel, the ASAN fails randomly. This was seen on Ubuntu 22.04.

This is also described at
https://stackoverflow.com/questions/77894856/possible-bug-in-gcc-sanitizers

Backport the fix from LLVM project, as gcc has not yet backported
anything for the 11 series.

Signed-off-by: Claus Stovgaard 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/gcc/gcc-11.4.inc|  1 +
 .../gcc/gcc/0031-gcc-sanitizers-fix.patch | 63 +++
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc/0031-gcc-sanitizers-fix.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.4.inc 
b/meta/recipes-devtools/gcc/gcc-11.4.inc
index 88310e6b79..fd6a3e92e3 100644
--- a/meta/recipes-devtools/gcc/gcc-11.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.4.inc
@@ -59,6 +59,7 @@ SRC_URI = "\

file://0028-debug-101473-apply-debug-prefix-maps-before-checksum.patch \
file://0029-Fix-install-path-of-linux64.h.patch \
file://0030-rust-recursion-limit.patch \
+   file://0031-gcc-sanitizers-fix.patch \
file://0001-CVE-2021-42574.patch \
file://0002-CVE-2021-42574.patch \
file://0003-CVE-2021-42574.patch \
diff --git a/meta/recipes-devtools/gcc/gcc/0031-gcc-sanitizers-fix.patch 
b/meta/recipes-devtools/gcc/gcc/0031-gcc-sanitizers-fix.patch
new file mode 100644
index 00..d63618132a
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc/0031-gcc-sanitizers-fix.patch
@@ -0,0 +1,63 @@
+From fb77ca05ffb4f8e666878f2f6718a9fb4d686839 Mon Sep 17 00:00:00 2001
+From: Thurston Dang 
+Date: Thu, 13 Apr 2023 23:55:01 +
+Subject: [PATCH] Re-land 'ASan: move allocator base to avoid conflict with
+ high-entropy ASLR for x86-64 Linux'
+
+D147984 was reverted because it broke lit tests on Mac. This revision is based 
on D147984
+but maintains the old behavior for Apple.
+
+Note that, per the follow-up discussion with MaskRay in D147984, this patch 
excludes Apple
+but includes other platforms (e.g., aarch64, MIPS64) and OSes (e.g., FreeBSD, 
S390X), not just
+x86-64 Linux.
+
+Original commit message from D147984:
+
+Users have discovered [*] that when CONFIG_ARCH_MMAP_RND_BITS == 32,
+it will frequently conflict with ASan's allocator on x86-64 Linux, because the
+PIE program segment base address of 0x5554 plus an ASLR shift of up to
+((2**32) * 4K == 0x1000) will sometimes exceed ASan's hardcoded
+base address of 0x6000. We fix this by simply moving the allocator base
+to 0x5000, which is below the PIE program segment base address. This is
+cleaner than trying to move it to another location that is sandwiched between
+the PIE program and library segments, because if either of those grow too 
large,
+it will collide with the allocator region.
+
+Note that we will never need to change this base address again (unless we want 
to increase
+the size of the allocator), because ASLR cannot be set above 32-bits for 
x86-64 Linux (the
+PIE program segment and library segments would collide with each other; see 
also
+ARCH_MMAP_RND_BITS_MAX in 
https://github.com/torvalds/linux/blob/master/arch/x86/Kconfig).
+
+[*] see https://b.corp.google.com/issues/276925478
+and 
https://groups.google.com/a/google.com/g/chrome-os-gardeners/c/BbfzCP3dEeo/m/h3C_vVUxCQAJ
+
+Differential Revision: https://reviews.llvm.org/D148280
+
+Upstream-Status: Backport from llvm-project: 
https://github.com/llvm/llvm-project/commit/fb77ca05ffb4f8e666878f2f6718a9fb4d686839
+Signed-off-by: Claus Stovgaard 
+---
+ libsanitizer/asan/asan_allocator.h | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/libsanitizer/asan/asan_allocator.h 
b/libsanitizer/asan/asan_allocator.h
+index 0b4dbf03bb9d53..6a12a6c6025283 100644
+--- a/libsanitizer/asan/asan_allocator.h
 b/libsanitizer/asan/asan_allocator.h
+@@ -143,11 +143,15 @@ typedef DefaultSizeClassMap SizeClassMap;
+ const uptr kAllocatorSpace = ~(uptr)0;
+ const uptr kAllocatorSize  =  0x80ULL;  // 500G
+ typedef DefaultSizeClassMap SizeClassMap;
+-# else
++#  elif SANITIZER_APPLE
+ const uptr kAllocatorSpace = 0x6000ULL;
+ const uptr kAllocatorSize  =  0x400ULL;  // 4T.
+ typedef DefaultSizeClassMap SizeClassMap;
+-# endif
++#  else
++const uptr kAllocatorSpace = 0x5000ULL;
++const uptr kAllocatorSize = 0x400ULL;  // 4T.
++typedef DefaultSizeClassMap SizeClassMap;
++#  endif
+ template 
+ struct AP64 {  // Allocator64 parameters. Deliberately using a short name.
+   static const uptr kSpaceBeg = kAllocatorSpace;
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197901): 
https://lists.openembedded.org/g/openembedded-core/message/197901
Mute This Topic: https://lists.openembedded.org/mt/105302706/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org

[OE-core][kirkstone 7/9] python3-urllib3: update to v1.26.18

2024-04-02 Thread Steve Sakoman
From: Tan Wen Yan 

https://github.com/urllib3/urllib3/releases/tag/1.26.18

Major changes in python3-urllib3 1.26.18:
- Made body stripped from HTTP requests changing the request method to GET 
after HTTP 303 "See Other" redirect responses. (CVE-2023-45803)

(cherry picked from OE-Core rev: 74da05b63634c248910594456dae286947f33da5)

Signed-off-by: Tan Wen Yan 
Signed-off-by: Steve Sakoman 
Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 .../{python3-urllib3_1.26.17.bb => python3-urllib3_1.26.18.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-urllib3_1.26.17.bb => 
python3-urllib3_1.26.18.bb} (86%)

diff --git a/meta/recipes-devtools/python/python3-urllib3_1.26.17.bb 
b/meta/recipes-devtools/python/python3-urllib3_1.26.18.bb
similarity index 86%
rename from meta/recipes-devtools/python/python3-urllib3_1.26.17.bb
rename to meta/recipes-devtools/python/python3-urllib3_1.26.18.bb
index 57b166870a..d384b5eb2f 100644
--- a/meta/recipes-devtools/python/python3-urllib3_1.26.17.bb
+++ b/meta/recipes-devtools/python/python3-urllib3_1.26.18.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://github.com/shazow/urllib3;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=c2823cb995439c984fd62a973d79815c"
 
-SRC_URI[sha256sum] = 
"24d6a242c28d29af46c3fae832c36db3bbebcc533dd1bb549172cd739c82df21"
+SRC_URI[sha256sum] = 
"f8ecc1bba5667413457c529ab955bf8c67b45db799d159066261719e328580a0"
 
 inherit pypi setuptools3
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197900): 
https://lists.openembedded.org/g/openembedded-core/message/197900
Mute This Topic: https://lists.openembedded.org/mt/105302705/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][kirkstone 6/9] tiff: fix CVE-2023-52356 CVE-2023-6277

2024-04-02 Thread Steve Sakoman
From: Lee Chee Yang 

import patch from ubuntu to fix CVE-2023-52356 CVE-2023-6277
import from
http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 .../libtiff/tiff/CVE-2023-52356.patch |  54 ++
 .../libtiff/tiff/CVE-2023-6277-1.patch| 178 ++
 .../libtiff/tiff/CVE-2023-6277-2.patch| 151 +++
 .../libtiff/tiff/CVE-2023-6277-3.patch|  46 +
 .../libtiff/tiff/CVE-2023-6277-4.patch|  93 +
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb |   5 +
 6 files changed, 527 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-2.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-3.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-4.patch

diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch 
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
new file mode 100644
index 00..4eb7d79c8f
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
@@ -0,0 +1,54 @@
+CVE: CVE-2023-52356
+Upstream-Status: Backport [upstream : 
https://gitlab.com/libtiff/libtiff/-/commit/51558511bdbbcffdce534db21dbaf5d54b31638a
 
+ubuntu : 
http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz
 ]
+Signed-off-by: Lee Chee Yang 
+
+[Ubuntu note: Backport of the following patch from upstream, with a few changes
+to match the current version of the file in the present Ubuntu release:
+ . using TIFFErrorExt instead of TIFFErrorExtR (the latter did not exist yet);
+-- Rodrigo Figueiredo Zaiden]
+
+Backport of:
+
+From 51558511bdbbcffdce534db21dbaf5d54b31638a Mon Sep 17 00:00:00 2001
+From: Even Rouault 
+Date: Tue, 31 Oct 2023 15:58:41 +0100
+Subject: [PATCH] TIFFReadRGBAStrip/TIFFReadRGBATile: add more validation of
+ col/row (fixes #622)
+
+---
+ libtiff/tif_getimage.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+
+--- tiff-4.3.0.orig/libtiff/tif_getimage.c
 tiff-4.3.0/libtiff/tif_getimage.c
+@@ -2942,6 +2942,13 @@ TIFFReadRGBAStripExt(TIFF* tif, uint32_t
+ }
+ 
+ if (TIFFRGBAImageOK(tif, emsg) && TIFFRGBAImageBegin(, tif, 
stop_on_error, emsg)) {
++if (row >= img.height)
++{
++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
++  "Invalid row passed to TIFFReadRGBAStrip().");
++TIFFRGBAImageEnd();
++return (0);
++}
+ 
+ img.row_offset = row;
+ img.col_offset = 0;
+@@ -3018,6 +3025,14 @@ TIFFReadRGBATileExt(TIFF* tif, uint32_t
+   return( 0 );
+ }
+ 
++if (col >= img.width || row >= img.height)
++{
++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
++  "Invalid row/col passed to TIFFReadRGBATile().");
++TIFFRGBAImageEnd();
++return (0);
++}
++
+ /*
+  * The TIFFRGBAImageGet() function doesn't allow us to get off the
+  * edge of the image, even to fill an otherwise valid tile.  So we
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch 
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
new file mode 100644
index 00..453df897ac
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
@@ -0,0 +1,178 @@
+CVE: CVE-2023-6277
+Upstream-Status: Backport [upstream : 
https://gitlab.com/libtiff/libtiff/-/commit/5320c9d89c054fa805d037d84c57da874470b01a
 
+ubuntu : 
http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz
 ]
+Signed-off-by: Lee Chee Yang 
+
+[Ubuntu note: Backport of the following patch from upstream, with a few changes
+to match the current version of the file in the present Ubuntu release:
+ . using TIFFWarningExt instead of TIFFWarningExtR (the latter did not exist 
yet);
+ . calling _TIFFfree(data) instead of _TIFFfreeExt(tif, data) (the latter did 
not exist yet);
+-- Rodrigo Figueiredo Zaiden]
+
+Backport of:
+
+From 5320c9d89c054fa805d037d84c57da874470b01a Mon Sep 17 00:00:00 2001
+From: Su Laus 
+Date: Tue, 31 Oct 2023 15:43:29 +
+Subject: [PATCH] Prevent some out-of-memory attacks
+
+Some small fuzzer files fake large amounts of data and provoke out-of-memory 
situations. For non-compressed data content / tags, out-of-memory can be 
prevented by comparing with the file size.
+
+At image reading, data size of some tags / data structures (StripByteCounts, 
StripOffsets, StripArray, TIFF directory) is compared with file size to prevent 
provoked out-of-memory attacks.
+
+See issue https://gitlab.com/libtiff/libtiff/-/issues/614#note_1602683857
+---
+ libtiff/tif_dirread.c | 92 ++-
+ 1 file changed, 90 

[OE-core][kirkstone 5/9] qemu: Fix for CVE-2023-6683

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

Upstream-Status: Backport from 
https://gitlab.com/qemu-project/qemu/-/commit/405484b29f6548c7b86549b0f961b906337aa68a

Reference: https://security-tracker.debian.org/tracker/CVE-2023-6683

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2023-6683.patch | 92 +++
 2 files changed, 93 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-6683.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index ad6b310137..4747310ae4 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -108,6 +108,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \

file://scsi-disk-allow-MODE-SELECT-block-desriptor-to-set-the-block-size.patch \

file://scsi-disk-ensure-block-size-is-non-zero-and-changes-limited-to-bits-8-15.patch
 \
file://CVE-2023-42467.patch \
+   file://CVE-2023-6683.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-6683.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2023-6683.patch
new file mode 100644
index 00..e528574076
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-6683.patch
@@ -0,0 +1,92 @@
+From 405484b29f6548c7b86549b0f961b906337aa68a Mon Sep 17 00:00:00 2001
+From: Fiona Ebner 
+Date: Wed, 24 Jan 2024 11:57:48 +0100
+Subject: [PATCH] ui/clipboard: mark type as not available when there is no
+ data
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+With VNC, a client can send a non-extended VNC_MSG_CLIENT_CUT_TEXT
+message with len=0. In qemu_clipboard_set_data(), the clipboard info
+will be updated setting data to NULL (because g_memdup(data, size)
+returns NULL when size is 0). If the client does not set the
+VNC_ENCODING_CLIPBOARD_EXT feature when setting up the encodings, then
+the 'request' callback for the clipboard peer is not initialized.
+Later, because data is NULL, qemu_clipboard_request() can be reached
+via vdagent_chr_write() and vdagent_clipboard_recv_request() and
+there, the clipboard owner's 'request' callback will be attempted to
+be called, but that is a NULL pointer.
+
+In particular, this can happen when using the KRDC (22.12.3) VNC
+client.
+
+Another scenario leading to the same issue is with two clients (say
+noVNC and KRDC):
+
+The noVNC client sets the extension VNC_FEATURE_CLIPBOARD_EXT and
+initializes its cbpeer.
+
+The KRDC client does not, but triggers a vnc_client_cut_text() (note
+it's not the _ext variant)). There, a new clipboard info with it as
+the 'owner' is created and via qemu_clipboard_set_data() is called,
+which in turn calls qemu_clipboard_update() with that info.
+
+In qemu_clipboard_update(), the notifier for the noVNC client will be
+called, i.e. vnc_clipboard_notify() and also set vs->cbinfo for the
+noVNC client. The 'owner' in that clipboard info is the clipboard peer
+for the KRDC client, which did not initialize the 'request' function.
+That sounds correct to me, it is the owner of that clipboard info.
+
+Then when noVNC sends a VNC_MSG_CLIENT_CUT_TEXT message (it did set
+the VNC_FEATURE_CLIPBOARD_EXT feature correctly, so a check for it
+passes), that clipboard info is passed to qemu_clipboard_request() and
+the original segfault still happens.
+
+Fix the issue by handling updates with size 0 differently. In
+particular, mark in the clipboard info that the type is not available.
+
+While at it, switch to g_memdup2(), because g_memdup() is deprecated.
+
+Cc: qemu-sta...@nongnu.org
+Fixes: CVE-2023-6683
+Reported-by: Markus Frank 
+Suggested-by: Marc-André Lureau 
+Signed-off-by: Fiona Ebner 
+Reviewed-by: Marc-André Lureau 
+Tested-by: Markus Frank 
+Message-ID: <20240124105749.204610-1-f.eb...@proxmox.com>
+
+Upstream-Status: Backport 
[https://gitlab.com/qemu-project/qemu/-/commit/405484b29f6548c7b86549b0f961b906337aa68a]
+CVE: CVE-2023-6683
+Signed-off-by: Vijay Anusuri 
+---
+ ui/clipboard.c | 12 +---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/ui/clipboard.c b/ui/clipboard.c
+index 3d14bffaf80..b3f6fa3c9e1 100644
+--- a/ui/clipboard.c
 b/ui/clipboard.c
+@@ -163,9 +163,15 @@ void qemu_clipboard_set_data(QemuClipboardPeer *peer,
+ }
+ 
+ g_free(info->types[type].data);
+-info->types[type].data = g_memdup(data, size);
+-info->types[type].size = size;
+-info->types[type].available = true;
++if (size) {
++info->types[type].data = g_memdup2(data, size);
++info->types[type].size = size;
++info->types[type].available = true;
++} else {
++info->types[type].data = NULL;
++info->types[type].size = 0;
++info->types[type].available = false;
++}
+ 
+ if (update) {
+ qemu_clipboard_update(info);
+-- 

[OE-core][kirkstone 3/9] expat: fix CVE-2023-52425

2024-04-02 Thread Steve Sakoman
From: Meenali Gupta 

libexpat through 2.5.0 allows a denial of service (resource consumption) because
many full reparsings are required in the case of a large token for which 
multiple
buffer fills are needed.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-52425

Changes related to test directory are not included as most of the files are not 
present
and are introduced in the later version.

Signed-off-by: Meenali Gupta 
Signed-off-by: Steve Sakoman 
---
 .../expat/expat/CVE-2023-52425-0001.patch |  40 
 .../expat/expat/CVE-2023-52425-0002.patch |  87 +++
 .../expat/expat/CVE-2023-52425-0003.patch | 222 ++
 .../expat/expat/CVE-2023-52425-0004.patch |  42 
 .../expat/expat/CVE-2023-52425-0005.patch |  69 ++
 .../expat/expat/CVE-2023-52425-0006.patch |  67 ++
 .../expat/expat/CVE-2023-52425-0007.patch | 159 +
 .../expat/expat/CVE-2023-52425-0008.patch |  95 
 .../expat/expat/CVE-2023-52425-0009.patch |  52 
 .../expat/expat/CVE-2023-52425-0010.patch | 111 +
 .../expat/expat/CVE-2023-52425-0011.patch |  89 +++
 .../expat/expat/CVE-2023-52425-0012.patch |  87 +++
 meta/recipes-core/expat/expat_2.5.0.bb|  12 +
 13 files changed, 1132 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0001.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0002.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0003.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0004.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0005.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0006.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0007.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0008.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0009.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0010.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0011.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0012.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2023-52425-0001.patch 
b/meta/recipes-core/expat/expat/CVE-2023-52425-0001.patch
new file mode 100644
index 00..4e21ade018
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2023-52425-0001.patch
@@ -0,0 +1,40 @@
+From d5b02e96ab95d2a7ae0aea72d00054b9d036d76d Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Thu, 9 Nov 2023 19:28:05 +0100
+Subject: [PATCH] xmlwf: Document argument "-q"
+
+Rebased-and-adapted-by: Snild Dolkow 
+
+CVE: CVE-2023-52425
+
+Upstream-Status: Backport 
[https://github.com/libexpat/libexpat/commit/d5b02e96ab95d2a7ae0aea72d00054b9d036d76d]
+
+Signed-off-by: Meenali Gupta 
+---
+ doc/xmlwf.xml | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/doc/xmlwf.xml b/doc/xmlwf.xml
+index 9603abf..3d35393 100644
+--- a/doc/xmlwf.xml
 b/doc/xmlwf.xml
+@@ -313,6 +313,16 @@ supports both.
+ 
+   
+ 
++  
++-q
++
++  
++Disable reparse deferral, and allow quadratic parse runtime
++on large tokens (default: reparse deferral enabled).
++  
++
++  
++
+   
+ -r
+ 
+-- 
+2.40.0
+
diff --git a/meta/recipes-core/expat/expat/CVE-2023-52425-0002.patch 
b/meta/recipes-core/expat/expat/CVE-2023-52425-0002.patch
new file mode 100644
index 00..8376727778
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2023-52425-0002.patch
@@ -0,0 +1,87 @@
+From 09fdf998e7cf3f8f9327e6602077791095aedd4d Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Thu, 9 Nov 2023 19:14:14 +0100
+Subject: [PATCH] xmlwf: Support disabling reparse deferral
+
+Rebased-and-adapted-by: Snild Dolkow 
+
+CVE: CVE-2023-52425
+
+Upstream-Status: Backport 
[https://github.com/libexpat/libexpat/commit/09fdf998e7cf3f8f9327e6602077791095aedd4d]
+
+Signed-off-by: Meenali Gupta 
+---
+ xmlwf/xmlwf.c  | 20 
+ xmlwf/xmlwf_helpgen.py |  4 
+ 2 files changed, 24 insertions(+)
+
+diff --git a/xmlwf/xmlwf.c b/xmlwf/xmlwf.c
+index dd023a9..9a5441c 100644
+--- a/xmlwf/xmlwf.c
 b/xmlwf/xmlwf.c
+@@ -911,6 +911,9 @@ usage(const XML_Char *prog, int rc) {
+   T("billion laughs attack protection:\n")
+   T("  NOTE: If you ever need to increase these values for non-attack 
payload, please file a bug report.\n")
+   T("\n")
++  T("reparse deferral:\n")
++  T("  -q disable reparse deferral, and allow [q]uadratic 
parse runtime with large tokens\n")
++  T("\n")
+   T("  -a FACTOR set maximum tolerated [a]mplification factor 
(default: 100.0)\n")
+   T("  -b BYTES  set number of output [b]ytes needed to activate 
(default: 8 MiB)\n")
+   T("\n")
+@@ -967,6 +970,8 @@ tmain(int argc, XML_Char **argv) {

[OE-core][kirkstone 4/9] curl: backport Debian patch for CVE-2024-2398

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

import patch from ubuntu to fix
 CVE-2024-2398

Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/curl/tree/debian/patches/?h=ubuntu%2Fjammy-security
Upstream commit 
https://github.com/curl/curl/commit/deca8039991886a559b67bcd6701db800a5cf764]

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 .../curl/curl/CVE-2024-2398.patch | 89 +++
 meta/recipes-support/curl/curl_7.82.0.bb  |  1 +
 2 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2024-2398.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2024-2398.patch 
b/meta/recipes-support/curl/curl/CVE-2024-2398.patch
new file mode 100644
index 00..ea55117f4d
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2024-2398.patch
@@ -0,0 +1,89 @@
+Backport of:
+
+From deca8039991886a559b67bcd6701db800a5cf764 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Wed, 6 Mar 2024 09:36:08 +0100
+Subject: [PATCH] http2: push headers better cleanup
+
+- provide common cleanup method for push headers
+
+Closes #13054
+
+Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/curl/tree/debian/patches/CVE-2024-2398.patch?h=ubuntu/jammy-security
+Upstream commit 
https://github.com/curl/curl/commit/deca8039991886a559b67bcd6701db800a5cf764]
+CVE: CVE-2024-2398
+Signed-off-by: Vijay Anusuri 
+---
+ lib/http2.c | 34 +++---
+ 1 file changed, 15 insertions(+), 19 deletions(-)
+
+--- a/lib/http2.c
 b/lib/http2.c
+@@ -555,6 +555,15 @@ static int set_transfer_url(struct Curl_
+   return 0;
+ }
+ 
++static void free_push_headers(struct HTTP *stream)
++{
++  size_t i;
++  for(i = 0; ipush_headers_used; i++)
++free(stream->push_headers[i]);
++  Curl_safefree(stream->push_headers);
++  stream->push_headers_used = 0;
++}
++
+ static int push_promise(struct Curl_easy *data,
+ struct connectdata *conn,
+ const nghttp2_push_promise *frame)
+@@ -568,7 +577,6 @@ static int push_promise(struct Curl_easy
+ struct curl_pushheaders heads;
+ CURLMcode rc;
+ struct http_conn *httpc;
+-size_t i;
+ /* clone the parent */
+ struct Curl_easy *newhandle = duphandle(data);
+ if(!newhandle) {
+@@ -604,11 +612,7 @@ static int push_promise(struct Curl_easy
+ Curl_set_in_callback(data, false);
+ 
+ /* free the headers again */
+-for(i = 0; ipush_headers_used; i++)
+-  free(stream->push_headers[i]);
+-free(stream->push_headers);
+-stream->push_headers = NULL;
+-stream->push_headers_used = 0;
++free_push_headers(stream);
+ 
+ if(rv) {
+   DEBUGASSERT((rv > CURL_PUSH_OK) && (rv <= CURL_PUSH_ERROROUT));
+@@ -1045,10 +1049,10 @@ static int on_header(nghttp2_session *se
+ stream->push_headers_alloc) {
+   char **headp;
+   stream->push_headers_alloc *= 2;
+-  headp = Curl_saferealloc(stream->push_headers,
+-   stream->push_headers_alloc * sizeof(char *));
++  headp = realloc(stream->push_headers,
++  stream->push_headers_alloc * sizeof(char *));
+   if(!headp) {
+-stream->push_headers = NULL;
++free_push_headers(stream);
+ return NGHTTP2_ERR_TEMPORAL_CALLBACK_FAILURE;
+   }
+   stream->push_headers = headp;
+@@ -1214,15 +1218,7 @@ void Curl_http2_done(struct Curl_easy *d
+  setup */
+   Curl_dyn_free(>header_recvbuf);
+   Curl_dyn_free(>trailer_recvbuf);
+-  if(http->push_headers) {
+-/* if they weren't used and then freed before */
+-for(; http->push_headers_used > 0; --http->push_headers_used) {
+-  free(http->push_headers[http->push_headers_used - 1]);
+-}
+-free(http->push_headers);
+-http->push_headers = NULL;
+-  }
+-
++  free_push_headers(http);
+   if(!(data->conn->handler->protocol_FAMILY_HTTP) ||
+  !httpc->h2) /* not HTTP/2 ? */
+ return;
diff --git a/meta/recipes-support/curl/curl_7.82.0.bb 
b/meta/recipes-support/curl/curl_7.82.0.bb
index 383cf415d9..72d8544e08 100644
--- a/meta/recipes-support/curl/curl_7.82.0.bb
+++ b/meta/recipes-support/curl/curl_7.82.0.bb
@@ -57,6 +57,7 @@ SRC_URI = "https://curl.se/download/${BP}.tar.xz \
file://CVE-2023-46219-0001.patch \
file://CVE-2023-46219-0002.patch \
file://CVE-2023-46219-0003.patch \
+   file://CVE-2024-2398.patch \
"
 SRC_URI[sha256sum] = 
"0aaa12d7bd04b0966254f2703ce80dd5c38dbbd76af0297d3d690cdce58a583c"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197897): 
https://lists.openembedded.org/g/openembedded-core/message/197897
Mute This Topic: https://lists.openembedded.org/mt/105302702/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]

[OE-core][kirkstone 2/9] xwayland: fix CVE-2023-6816 CVE-2024-0408/0409

2024-04-02 Thread Steve Sakoman
From: Lee Chee Yang 

fix CVE-2023-6816 CVE-2024-0408 CVE-2024-0409

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 .../xwayland/xwayland/CVE-2023-6816.patch | 57 
 .../xwayland/xwayland/CVE-2024-0408.patch | 65 +++
 .../xwayland/xwayland/CVE-2024-0409.patch | 47 ++
 .../xwayland/xwayland_22.1.8.bb   |  3 +
 4 files changed, 172 insertions(+)
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2023-6816.patch
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2024-0408.patch
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2024-0409.patch

diff --git a/meta/recipes-graphics/xwayland/xwayland/CVE-2023-6816.patch 
b/meta/recipes-graphics/xwayland/xwayland/CVE-2023-6816.patch
new file mode 100644
index 00..5c68bfb3c1
--- /dev/null
+++ b/meta/recipes-graphics/xwayland/xwayland/CVE-2023-6816.patch
@@ -0,0 +1,57 @@
+CVE: CVE-2023-6816
+Upstream-Status: Backport [ 
https://gitlab.freedesktop.org/xorg/xserver/-/commit/b5cb27032d3e486ba84a491e1420e85171c4c0a3
 ]
+Signed-off-by: Lee Chee Yang 
+
+From b5cb27032d3e486ba84a491e1420e85171c4c0a3 Mon Sep 17 00:00:00 2001
+From: Peter Hutterer 
+Date: Thu, 14 Dec 2023 11:29:49 +1000
+Subject: [PATCH] dix: allocate enough space for logical button maps
+
+Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for
+each logical button currently down. Since buttons can be arbitrarily mapped
+to anything up to 255 make sure we have enough bits for the maximum mapping.
+
+CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665
+
+This vulnerability was discovered by:
+Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
+
+(cherry picked from commit 9e2ecb2af8302dedc49cb6a63ebe063c58a9e7e3)
+---
+ Xi/xiquerypointer.c | 3 +--
+ dix/enterleave.c| 5 +++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/Xi/xiquerypointer.c b/Xi/xiquerypointer.c
+index 5b77b1a444..2b05ac5f39 100644
+--- a/Xi/xiquerypointer.c
 b/Xi/xiquerypointer.c
+@@ -149,8 +149,7 @@ ProcXIQueryPointer(ClientPtr client)
+ if (pDev->button) {
+ int i;
+ 
+-rep.buttons_len =
+-bytes_to_int32(bits_to_bytes(pDev->button->numButtons));
++rep.buttons_len = bytes_to_int32(bits_to_bytes(256)); /* button map 
up to 255 */
+ rep.length += rep.buttons_len;
+ buttons = calloc(rep.buttons_len, 4);
+ if (!buttons)
+diff --git a/dix/enterleave.c b/dix/enterleave.c
+index 867ec74363..ded8679d76 100644
+--- a/dix/enterleave.c
 b/dix/enterleave.c
+@@ -784,8 +784,9 @@ DeviceFocusEvent(DeviceIntPtr dev, int type, int mode, int 
detail,
+ 
+ mouse = IsFloating(dev) ? dev : GetMaster(dev, MASTER_POINTER);
+ 
+-/* XI 2 event */
+-btlen = (mouse->button) ? bits_to_bytes(mouse->button->numButtons) : 0;
++/* XI 2 event contains the logical button map - maps are CARD8
++ * so we need 256 bits for the possibly maximum mapping */
++btlen = (mouse->button) ? bits_to_bytes(256) : 0;
+ btlen = bytes_to_int32(btlen);
+ len = sizeof(xXIFocusInEvent) + btlen * 4;
+ 
+-- 
+GitLab
+
diff --git a/meta/recipes-graphics/xwayland/xwayland/CVE-2024-0408.patch 
b/meta/recipes-graphics/xwayland/xwayland/CVE-2024-0408.patch
new file mode 100644
index 00..9063cd00b2
--- /dev/null
+++ b/meta/recipes-graphics/xwayland/xwayland/CVE-2024-0408.patch
@@ -0,0 +1,65 @@
+CVE: CVE-2024-0408
+Upstream-Status: Backport [ 
https://gitlab.freedesktop.org/xorg/xserver/-/commit/4093057b98bc5a178f130c9ba6b0b28385e24ae5
 ]
+Signed-off-by: Lee Chee Yang 
+
+From 4093057b98bc5a178f130c9ba6b0b28385e24ae5 Mon Sep 17 00:00:00 2001
+From: Olivier Fourdan 
+Date: Wed, 6 Dec 2023 12:09:41 +0100
+Subject: [PATCH] glx: Call XACE hooks on the GLX buffer
+
+The XSELINUX code will label resources at creation by checking the
+access mode. When the access mode is DixCreateAccess, it will call the
+function to label the new resource SELinuxLabelResource().
+
+However, GLX buffers do not go through the XACE hooks when created,
+hence leaving the resource actually unlabeled.
+
+When, later, the client tries to create another resource using that
+drawable (like a GC for example), the XSELINUX code would try to use
+the security ID of that object which has never been labeled, get a NULL
+pointer and crash when checking whether the requested permissions are
+granted for subject security ID.
+
+To avoid the issue, make sure to call the XACE hooks when creating the
+GLX buffers.
+
+Credit goes to Donn Seeley  for providing the patch.
+
+CVE-2024-0408
+
+Signed-off-by: Olivier Fourdan 
+Acked-by: Peter Hutterer 
+(cherry picked from commit e5e8586a12a3ec915673edffa10dc8fe5e15dac3)
+---
+ glx/glxcmds.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/glx/glxcmds.c b/glx/glxcmds.c
+index fc26a2e345..1e46d0c723 100644
+--- a/glx/glxcmds.c
 b/glx/glxcmds.c
+@@ -48,6 +48,7 @@
+ #include "indirect_util.h"
+ #include 

[OE-core][kirkstone 1/9] nghttp2: fix CVE-2023-44487

2024-04-02 Thread Steve Sakoman
From: aszh07 

The HTTP/2 protocol allows a denial of service (server resource consumption)
because request cancellation can reset many streams quickly, as exploited in
the wild in August through October 2023.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-44487
https://github.com/nghttp2/nghttp2/commit/72b4af6143681f528f1d237b21a9a7aee1738832

Signed-off-by: Zahir Hussain 
Signed-off-by: Steve Sakoman 
---
 .../nghttp2/nghttp2/CVE-2023-44487.patch  | 927 ++
 .../recipes-support/nghttp2/nghttp2_1.47.0.bb |   1 +
 2 files changed, 928 insertions(+)
 create mode 100644 meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch

diff --git a/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch 
b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
new file mode 100644
index 00..3cba83307c
--- /dev/null
+++ b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
@@ -0,0 +1,927 @@
+From 72b4af6143681f528f1d237b21a9a7aee1738832 Mon Sep 17 00:00:00 2001
+From: Tatsuhiro Tsujikawa 
+Date: Sun, 1 Oct 2023 00:05:01 +0900
+Subject: [PATCH] Rework session management
+
+CVE: CVE-2023-44487
+
+Upstream-Status: Backport 
[https://github.com/nghttp2/nghttp2/commit/72b4af6143681f528f1d237b21a9a7aee1738832]
+
+Signed-off-by: Zahir Hussain zahir.ba...@kpit.com
+Signed-off-by: aszh07 
+---
+CMakeLists.txt |   4 ++
+cmakeconfig.h.in   |   9 +++
+configure.ac   |  21 +++
+doc/Makefile.am|   1 +
+lib/CMakeLists.txt |   2 +
+lib/Makefile.am|   4 ++
+lib/includes/nghttp2/nghttp2.h |  17 ++
+lib/nghttp2_option.c   |   7 +++
+lib/nghttp2_ratelim.c  |  75 
+lib/nghttp2_ratelim.h  |  57 ++
+lib/nghttp2_session.c  |  34 ++-
+lib/nghttp2_session.h  |  12 +++-
+lib/nghttp2_time.c |  62 
+lib/nghttp2_time.h |  38 
+tests/nghttp2_ratelim_test.c   | 101 
+tests/nghttp2_ratelim_test.h   |  35 +++
+tests/nghttp2_session_test.c   | 103 +
+tests/nghttp2_session_test.h   |   1 +
+tests/CMakeLists.txt   |   1 +
+tests/Makefile.am  |   6 +-
+lib/nghttp2_option.h   |   6 ++
+tests/main.c   |   7 ++-
+22 files changed, 598 insertions(+), 5 deletions(-)
+create mode 100644 lib/nghttp2_ratelim.c
+create mode 100644 lib/nghttp2_ratelim.h
+create mode 100644 lib/nghttp2_time.c
+create mode 100644 lib/nghttp2_time.h
+create mode 100644 tests/nghttp2_ratelim_test.c
+create mode 100644 tests/nghttp2_ratelim_test.h
+
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -262,6 +262,7 @@ check_include_file("netinet/in.h"   HAVE
+ check_include_file("pwd.h"  HAVE_PWD_H)
+ check_include_file("sys/socket.h"   HAVE_SYS_SOCKET_H)
+ check_include_file("sys/time.h" HAVE_SYS_TIME_H)
++check_include_file("sysinfoapi.h"   HAVE_SYSINFOAPI_H)
+ check_include_file("syslog.h"   HAVE_SYSLOG_H)
+ check_include_file("time.h" HAVE_TIME_H)
+ check_include_file("unistd.h"   HAVE_UNISTD_H)
+@@ -302,8 +303,11 @@ check_type_size("time_t"  SIZEOF_TIME_T)
+ include(CheckFunctionExists)
+ check_function_exists(_Exit HAVE__EXIT)
+ check_function_exists(accept4   HAVE_ACCEPT4)
++check_function_exists(clock_gettime HAVE_CLOCK_GETTIME)
+ check_function_exists(mkostemp  HAVE_MKOSTEMP)
+ 
++check_symbol_exists(GetTickCount64 sysinfoapi.h HAVE_GETTICKCOUNT64)
++
+ include(CheckSymbolExists)
+ # XXX does this correctly detect initgroups (un)availability on cygwin?
+ check_symbol_exists(initgroups grp.h HAVE_DECL_INITGROUPS)
+--- a/cmakeconfig.h.in
 b/cmakeconfig.h.in
+@@ -34,9 +34,15 @@
+ /* Define to 1 if you have the `accept4` function. */
+ #cmakedefine HAVE_ACCEPT4 1
+ 
++/* Define to 1 if you have the `clock_gettime` function. */
++#cmakedefine HAVE_CLOCK_GETTIME 1
++
+ /* Define to 1 if you have the `mkostemp` function. */
+ #cmakedefine HAVE_MKOSTEMP 1
+ 
++/* Define to 1 if you have the `GetTickCount64` function. */
++#cmakedefine HAVE_GETTICKCOUNT64 1
++
+ /* Define to 1 if you have the `initgroups` function. */
+ #cmakedefine01 HAVE_DECL_INITGROUPS
+ 
+@@ -73,6 +79,9 @@
+ /* Define to 1 if you have the  header file. */
+ #cmakedefine HAVE_SYS_TIME_H 1
+ 
++/* Define to 1 if you have the  header file. */
++#cmakedefine HAVE_SYSINFOAPI_H 1
++
+ /* Define to 1 if you have the  header file. */
+ #cmakedefine HAVE_SYSLOG_H 1
+ 
+--- a/configure.ac
 b/configure.ac
+@@ -607,6 +607,7 @@ AC_CHECK_HEADERS([ \
+   string.h \
+   sys/socket.h \
+   sys/time.h \
++  sysinfoapi.h \
+   syslog.h \
+   time.h \
+   unistd.h \
+@@ -681,6 +682,7 @@ AC_FUNC_STRNLEN
+ AC_CHECK_FUNCS([ \
+   _Exit \
+   accept4 \
++  clock_gettime \
+   dup2 \
+   getcwd \
+   getpwnam \
+@@ -706,6 +708,25 @@ AC_CHECK_FUNCS([ \
+ AC_CHECK_FUNC([timerfd_create],
+   

[OE-core][kirkstone 0/9] Patch review

2024-04-02 Thread Steve Sakoman
Please review this set of changes for kirkstone and have comments back by
end of day Thursday, April 4

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6758

The following changes since commit 1b5405955c7c2579ed1f52522e2e177d0281fa33:

  glibc: Fix subscript typos for get_nscd_addresses (2024-03-19 03:33:32 -1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/kirkstone-nut
  
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

Claus Stovgaard (1):
  gcc: Backport sanitizer fix for 32-bit ALSR

Colin McAllister (1):
  common-licenses: Backport missing license

Lee Chee Yang (2):
  xwayland: fix CVE-2023-6816 CVE-2024-0408/0409
  tiff: fix CVE-2023-52356 CVE-2023-6277

Meenali Gupta (1):
  expat: fix CVE-2023-52425

Tan Wen Yan (1):
  python3-urllib3: update to v1.26.18

Vijay Anusuri (2):
  curl: backport Debian patch for CVE-2024-2398
  qemu: Fix for CVE-2023-6683

aszh07 (1):
  nghttp2: fix CVE-2023-44487

 .../LGPL-3.0-with-zeromq-exception| 181 
 .../expat/expat/CVE-2023-52425-0001.patch |  40 +
 .../expat/expat/CVE-2023-52425-0002.patch |  87 ++
 .../expat/expat/CVE-2023-52425-0003.patch | 222 +
 .../expat/expat/CVE-2023-52425-0004.patch |  42 +
 .../expat/expat/CVE-2023-52425-0005.patch |  69 ++
 .../expat/expat/CVE-2023-52425-0006.patch |  67 ++
 .../expat/expat/CVE-2023-52425-0007.patch | 159 +++
 .../expat/expat/CVE-2023-52425-0008.patch |  95 ++
 .../expat/expat/CVE-2023-52425-0009.patch |  52 +
 .../expat/expat/CVE-2023-52425-0010.patch | 111 +++
 .../expat/expat/CVE-2023-52425-0011.patch |  89 ++
 .../expat/expat/CVE-2023-52425-0012.patch |  87 ++
 meta/recipes-core/expat/expat_2.5.0.bb|  12 +
 meta/recipes-devtools/gcc/gcc-11.4.inc|   1 +
 .../gcc/gcc/0031-gcc-sanitizers-fix.patch |  63 ++
 ..._1.26.17.bb => python3-urllib3_1.26.18.bb} |   2 +-
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 .../qemu/qemu/CVE-2023-6683.patch |  92 ++
 .../xwayland/xwayland/CVE-2023-6816.patch |  57 ++
 .../xwayland/xwayland/CVE-2024-0408.patch |  65 ++
 .../xwayland/xwayland/CVE-2024-0409.patch |  47 +
 .../xwayland/xwayland_22.1.8.bb   |   3 +
 .../libtiff/tiff/CVE-2023-52356.patch |  54 +
 .../libtiff/tiff/CVE-2023-6277-1.patch| 178 
 .../libtiff/tiff/CVE-2023-6277-2.patch| 151 +++
 .../libtiff/tiff/CVE-2023-6277-3.patch|  46 +
 .../libtiff/tiff/CVE-2023-6277-4.patch|  93 ++
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb |   5 +
 .../curl/curl/CVE-2024-2398.patch |  89 ++
 meta/recipes-support/curl/curl_7.82.0.bb  |   1 +
 .../nghttp2/nghttp2/CVE-2023-44487.patch  | 927 ++
 .../recipes-support/nghttp2/nghttp2_1.47.0.bb |   1 +
 33 files changed, 3188 insertions(+), 1 deletion(-)
 create mode 100644 meta/files/common-licenses/LGPL-3.0-with-zeromq-exception
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0001.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0002.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0003.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0004.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0005.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0006.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0007.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0008.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0009.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0010.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0011.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52425-0012.patch
 create mode 100644 meta/recipes-devtools/gcc/gcc/0031-gcc-sanitizers-fix.patch
 rename meta/recipes-devtools/python/{python3-urllib3_1.26.17.bb => 
python3-urllib3_1.26.18.bb} (86%)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-6683.patch
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2023-6816.patch
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2024-0408.patch
 create mode 100644 meta/recipes-graphics/xwayland/xwayland/CVE-2024-0409.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-2.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-3.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-4.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2024-2398.patch
 create mode 100644 

[OE-core][dunfell 7/7] perf: bump PR to deal with sstate corruption on autobuilder

2024-04-02 Thread Steve Sakoman
Testing of an SPDX patch corrupted sstate, so bump PR to work around the issue

Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/perf/perf.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 91bf648caa..42621e47d3 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -9,7 +9,7 @@ HOMEPAGE = "https://perf.wiki.kernel.org/index.php/Main_Page;
 
 LICENSE = "GPLv2"
 
-PR = "r9"
+PR = "r10"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197892): 
https://lists.openembedded.org/g/openembedded-core/message/197892
Mute This Topic: https://lists.openembedded.org/mt/105302364/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][dunfell 5/7] openssl: Fix CVE-2024-0727

2024-04-02 Thread Steve Sakoman
From: virendra thakur 

PKCS12 structures contain PKCS7 ContentInfo fields. These fields are
optional and can be NULL even if the "type" is a valid value. OpenSSL
was not properly accounting for this and a NULL dereference can occur
causing a crash.

Signed-off-by: virendra thakur 
Signed-off-by: Steve Sakoman 
---
 .../openssl/openssl/CVE-2024-0727.patch   | 122 ++
 .../openssl/openssl_1.1.1w.bb |   1 +
 2 files changed, 123 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2024-0727.patch

diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2024-0727.patch 
b/meta/recipes-connectivity/openssl/openssl/CVE-2024-0727.patch
new file mode 100644
index 00..3da6879ccb
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/CVE-2024-0727.patch
@@ -0,0 +1,122 @@
+Backport of:
+
+From 09df4395b5071217b76dc7d3d2e630eb8c5a79c2 Mon Sep 17 00:00:00 2001
+From: Matt Caswell 
+Date: Fri, 19 Jan 2024 11:28:58 +
+Subject: [PATCH] Add NULL checks where ContentInfo data can be NULL
+
+PKCS12 structures contain PKCS7 ContentInfo fields. These fields are
+optional and can be NULL even if the "type" is a valid value. OpenSSL
+was not properly accounting for this and a NULL dereference can occur
+causing a crash.
+
+CVE-2024-0727
+
+Reviewed-by: Tomas Mraz 
+Reviewed-by: Hugo Landau 
+Reviewed-by: Neil Horman 
+(Merged from https://github.com/openssl/openssl/pull/23362)
+
+(cherry picked from commit d135eeab8a5dbf72b3da5240bab9ddb7678dbd2c)
+
+Upstream-Status: Backport 
[https://github.com/openssl/openssl/commit/d135eeab8a5dbf72b3da5240bab9ddb7678dbd2c]
+
+CVE: CVE-2024-0727
+
+Signed-off-by: virendra thakur 
+---
+ crypto/pkcs12/p12_add.c  | 18 ++
+ crypto/pkcs12/p12_mutl.c |  5 +
+ crypto/pkcs12/p12_npas.c |  5 +++--
+ crypto/pkcs7/pk7_mime.c  |  7 +--
+ 4 files changed, 31 insertions(+), 4 deletions(-)
+
+--- a/crypto/pkcs12/p12_add.c
 b/crypto/pkcs12/p12_add.c
+@@ -76,6 +76,13 @@ STACK_OF(PKCS12_SAFEBAG) *PKCS12_unpack_
+   PKCS12_R_CONTENT_TYPE_NOT_DATA);
+ return NULL;
+ }
++
++if (p7->d.data == NULL) {
++PKCS12err(PKCS12_F_PKCS12_UNPACK_P7DATA,
++  PKCS12_R_DECODE_ERROR);
++return NULL;
++}
++
+ return ASN1_item_unpack(p7->d.data, ASN1_ITEM_rptr(PKCS12_SAFEBAGS));
+ }
+ 
+@@ -132,6 +139,12 @@ STACK_OF(PKCS12_SAFEBAG) *PKCS12_unpack_
+ {
+ if (!PKCS7_type_is_encrypted(p7))
+ return NULL;
++
++if (p7->d.encrypted == NULL) {
++PKCS12err(PKCS12_F_PKCS12_UNPACK_P7DATA, PKCS12_R_DECODE_ERROR);
++return NULL;
++}
++
+ return PKCS12_item_decrypt_d2i(p7->d.encrypted->enc_data->algorithm,
+ASN1_ITEM_rptr(PKCS12_SAFEBAGS),
+pass, passlen,
+@@ -159,6 +172,13 @@ STACK_OF(PKCS7) *PKCS12_unpack_authsafes
+   PKCS12_R_CONTENT_TYPE_NOT_DATA);
+ return NULL;
+ }
++
++if (p12->authsafes->d.data == NULL) {
++PKCS12err(PKCS12_F_PKCS12_UNPACK_AUTHSAFES,
++  PKCS12_R_DECODE_ERROR);
++return NULL;
++}
++
+ return ASN1_item_unpack(p12->authsafes->d.data,
+ ASN1_ITEM_rptr(PKCS12_AUTHSAFES));
+ }
+--- a/crypto/pkcs12/p12_mutl.c
 b/crypto/pkcs12/p12_mutl.c
+@@ -93,6 +93,11 @@ static int pkcs12_gen_mac(PKCS12 *p12, c
+ return 0;
+ }
+ 
++if (p12->authsafes->d.data == NULL) {
++PKCS12err(PKCS12_F_PKCS12_GEN_MAC, PKCS12_R_DECODE_ERROR);
++return 0;
++}
++
+ salt = p12->mac->salt->data;
+ saltlen = p12->mac->salt->length;
+ if (!p12->mac->iter)
+--- a/crypto/pkcs12/p12_npas.c
 b/crypto/pkcs12/p12_npas.c
+@@ -78,8 +78,9 @@ static int newpass_p12(PKCS12 *p12, cons
+ bags = PKCS12_unpack_p7data(p7);
+ } else if (bagnid == NID_pkcs7_encrypted) {
+ bags = PKCS12_unpack_p7encdata(p7, oldpass, -1);
+-if (!alg_get(p7->d.encrypted->enc_data->algorithm,
+- _nid, _iter, _saltlen))
++if (p7->d.encrypted == NULL
++|| !alg_get(p7->d.encrypted->enc_data->algorithm,
++_nid, _iter, _saltlen))
+ goto err;
+ } else {
+ continue;
+--- a/crypto/pkcs7/pk7_mime.c
 b/crypto/pkcs7/pk7_mime.c
+@@ -30,10 +30,13 @@ int SMIME_write_PKCS7(BIO *bio, PKCS7 *p
+ {
+ STACK_OF(X509_ALGOR) *mdalgs;
+ int ctype_nid = OBJ_obj2nid(p7->type);
+-if (ctype_nid == NID_pkcs7_signed)
++if (ctype_nid == NID_pkcs7_signed) {
++if (p7->d.sign == NULL)
++return 0;
+ mdalgs = p7->d.sign->md_algs;
+-else
++} else {
+ mdalgs = NULL;
++}
+ 
+ flags ^= SMIME_OLDMIME;
+ 
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1w.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1w.bb
index 8a53b06862..0e490eabc3 

[OE-core][dunfell 6/7] tar: bump PR to deal with sstate corruption on autobuilder

2024-04-02 Thread Steve Sakoman
Testing of an SPDX patch corrupted sstate, so bump PR to work around the issue

Signed-off-by: Steve Sakoman 
---
 meta/recipes-extended/tar/tar_1.32.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/tar/tar_1.32.bb 
b/meta/recipes-extended/tar/tar_1.32.bb
index c560741599..9297480e85 100644
--- a/meta/recipes-extended/tar/tar_1.32.bb
+++ b/meta/recipes-extended/tar/tar_1.32.bb
@@ -6,6 +6,8 @@ SECTION = "base"
 LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
+PR = "r1"
+
 SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2 \
file://musl_dirent.patch \
file://CVE-2021-20193.patch \
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197891): 
https://lists.openembedded.org/g/openembedded-core/message/197891
Mute This Topic: https://lists.openembedded.org/mt/105302363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][dunfell 4/7] curl: backport Debian patch for CVE-2024-2398

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

import patch from ubuntu to fix
 CVE-2024-2398

Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/curl/tree/debian/patches/?h=ubuntu%2Ffocal-security
Upstream commit
https://github.com/curl/curl/commit/deca8039991886a559b67bcd6701db800a5cf764]

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 .../curl/curl/CVE-2024-2398.patch | 88 +++
 meta/recipes-support/curl/curl_7.69.1.bb  |  1 +
 2 files changed, 89 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2024-2398.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2024-2398.patch 
b/meta/recipes-support/curl/curl/CVE-2024-2398.patch
new file mode 100644
index 00..a3840336f0
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2024-2398.patch
@@ -0,0 +1,88 @@
+Backport of:
+
+From deca8039991886a559b67bcd6701db800a5cf764 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Wed, 6 Mar 2024 09:36:08 +0100
+Subject: [PATCH] http2: push headers better cleanup
+
+- provide common cleanup method for push headers
+
+Closes #13054
+
+Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/curl/tree/debian/patches/CVE-2024-2398.patch?h=ubuntu/focal-security
+Upstream commit 
https://github.com/curl/curl/commit/deca8039991886a559b67bcd6701db800a5cf764]
+CVE: CVE-2024-2398
+Signed-off-by: Vijay Anusuri 
+---
+ lib/http2.c | 34 +++---
+ 1 file changed, 15 insertions(+), 19 deletions(-)
+
+--- a/lib/http2.c
 b/lib/http2.c
+@@ -515,6 +515,15 @@ static struct Curl_easy *duphandle(struc
+ }
+ 
+ 
++static void free_push_headers(struct HTTP *stream)
++{
++  size_t i;
++  for(i = 0; ipush_headers_used; i++)
++free(stream->push_headers[i]);
++  Curl_safefree(stream->push_headers);
++  stream->push_headers_used = 0;
++}
++
+ static int push_promise(struct Curl_easy *data,
+ struct connectdata *conn,
+ const nghttp2_push_promise *frame)
+@@ -528,7 +537,6 @@ static int push_promise(struct Curl_easy
+ struct curl_pushheaders heads;
+ CURLMcode rc;
+ struct http_conn *httpc;
+-size_t i;
+ /* clone the parent */
+ struct Curl_easy *newhandle = duphandle(data);
+ if(!newhandle) {
+@@ -557,11 +565,7 @@ static int push_promise(struct Curl_easy
+ Curl_set_in_callback(data, false);
+ 
+ /* free the headers again */
+-for(i = 0; ipush_headers_used; i++)
+-  free(stream->push_headers[i]);
+-free(stream->push_headers);
+-stream->push_headers = NULL;
+-stream->push_headers_used = 0;
++free_push_headers(stream);
+ 
+ if(rv) {
+   /* denied, kill off the new handle again */
+@@ -995,10 +999,10 @@ static int on_header(nghttp2_session *se
+ stream->push_headers_alloc) {
+   char **headp;
+   stream->push_headers_alloc *= 2;
+-  headp = Curl_saferealloc(stream->push_headers,
+-   stream->push_headers_alloc * sizeof(char *));
++  headp = realloc(stream->push_headers,
++  stream->push_headers_alloc * sizeof(char *));
+   if(!headp) {
+-stream->push_headers = NULL;
++free_push_headers(stream);
+ return NGHTTP2_ERR_TEMPORAL_CALLBACK_FAILURE;
+   }
+   stream->push_headers = headp;
+@@ -1179,14 +1183,7 @@ void Curl_http2_done(struct Curl_easy *d
+   if(http->header_recvbuf) {
+ Curl_add_buffer_free(>header_recvbuf);
+ Curl_add_buffer_free(>trailer_recvbuf);
+-if(http->push_headers) {
+-  /* if they weren't used and then freed before */
+-  for(; http->push_headers_used > 0; --http->push_headers_used) {
+-free(http->push_headers[http->push_headers_used - 1]);
+-  }
+-  free(http->push_headers);
+-  http->push_headers = NULL;
+-}
++free_push_headers(http);
+   }
+ 
+   if(!httpc->h2) /* not HTTP/2 ? */
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb 
b/meta/recipes-support/curl/curl_7.69.1.bb
index 980b4224a8..2f351d585a 100644
--- a/meta/recipes-support/curl/curl_7.69.1.bb
+++ b/meta/recipes-support/curl/curl_7.69.1.bb
@@ -58,6 +58,7 @@ SRC_URI = "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://CVE-2023-28321.patch \
file://CVE-2023-28322.patch \
file://CVE-2023-46218.patch \
+   file://CVE-2024-2398.patch \
 "
 
 SRC_URI[md5sum] = "ec5fc263f898a3dfef08e805f1ecca42"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197889): 
https://lists.openembedded.org/g/openembedded-core/message/197889
Mute This Topic: https://lists.openembedded.org/mt/105302361/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][dunfell 3/7] tar: Fix for CVE-2023-39804

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

Upstream-Status: Backport from 
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 .../tar/tar/CVE-2023-39804.patch  | 64 +++
 meta/recipes-extended/tar/tar_1.32.bb |  1 +
 2 files changed, 65 insertions(+)
 create mode 100644 meta/recipes-extended/tar/tar/CVE-2023-39804.patch

diff --git a/meta/recipes-extended/tar/tar/CVE-2023-39804.patch 
b/meta/recipes-extended/tar/tar/CVE-2023-39804.patch
new file mode 100644
index 00..f550928540
--- /dev/null
+++ b/meta/recipes-extended/tar/tar/CVE-2023-39804.patch
@@ -0,0 +1,64 @@
+From a339f05cd269013fa133d2f148d73f6f7d4247e4 Mon Sep 17 00:00:00 2001
+From: Sergey Poznyakoff 
+Date: Sat, 28 Aug 2021 16:02:12 +0300
+Subject: Fix handling of extended header prefixes
+
+* src/xheader.c (locate_handler): Recognize prefix keywords only
+when followed by a dot.
+(xattr_decoder): Use xmalloc/xstrdup instead of alloc
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4]
+CVE: CVE-2023-39804
+Signed-off-by: Vijay Anusuri 
+---
+ src/xheader.c | 17 +
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/src/xheader.c b/src/xheader.c
+index 4f8b2b2..3cd694d 100644
+--- a/src/xheader.c
 b/src/xheader.c
+@@ -637,11 +637,11 @@ static struct xhdr_tab const *
+ locate_handler (char const *keyword)
+ {
+   struct xhdr_tab const *p;
+-
+   for (p = xhdr_tab; p->keyword; p++)
+ if (p->prefix)
+   {
+-if (strncmp (p->keyword, keyword, strlen(p->keyword)) == 0)
++  size_t kwlen = strlen (p->keyword);
++if (keyword[kwlen] == '.' && strncmp (p->keyword, keyword, kwlen) == 
0)
+   return p;
+   }
+ else
+@@ -1716,19 +1716,20 @@ xattr_decoder (struct tar_stat_info *st,
+char const *keyword, char const *arg, size_t size)
+ {
+   char *xstr, *xkey;
+-
++  
+   /* copy keyword */
+-  size_t klen_raw = strlen (keyword);
+-  xkey = alloca (klen_raw + 1);
+-  memcpy (xkey, keyword, klen_raw + 1) /* including null-terminating */;
++  xkey = xstrdup (keyword);
+ 
+   /* copy value */
+-  xstr = alloca (size + 1);
++  xstr = xmalloc (size + 1);
+   memcpy (xstr, arg, size + 1); /* separator included, for GNU tar '\n' */;
+ 
+   xattr_decode_keyword (xkey);
+ 
+-  xheader_xattr_add (st, xkey + strlen("SCHILY.xattr."), xstr, size);
++  xheader_xattr_add (st, xkey + strlen ("SCHILY.xattr."), xstr, size);
++
++  free (xkey);
++  free (xstr);
+ }
+ 
+ static void
+-- 
+cgit v1.1
+
diff --git a/meta/recipes-extended/tar/tar_1.32.bb 
b/meta/recipes-extended/tar/tar_1.32.bb
index 1246f01256..c560741599 100644
--- a/meta/recipes-extended/tar/tar_1.32.bb
+++ b/meta/recipes-extended/tar/tar_1.32.bb
@@ -10,6 +10,7 @@ SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2 \
file://musl_dirent.patch \
file://CVE-2021-20193.patch \
file://CVE-2022-48303.patch \
+   file://CVE-2023-39804.patch \
 "
 
 SRC_URI[md5sum] = "17917356fff5cb4bd3cd5a6c3e727b05"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197888): 
https://lists.openembedded.org/g/openembedded-core/message/197888
Mute This Topic: https://lists.openembedded.org/mt/105302360/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][dunfell 2/7] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

Upstream-Status: Backport
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1
&
https://github.com/golang/go/commit/bf80213b121074f4ad9b449410a4d13bae5e9be0
&
https://github.com/golang/go/commit/3643147a29352ca2894fd5d0d2069bc4b4335a7e]

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.14.inc  |   3 +
 .../go/go-1.14/CVE-2023-45289.patch   | 121 
 .../go/go-1.14/CVE-2023-45290.patch   | 271 ++
 .../go/go-1.14/CVE-2024-24785.patch   | 197 +
 4 files changed, 592 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45290.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2024-24785.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index 4fbf9d7590..69b65f3eb2 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -88,6 +88,9 @@ SRC_URI += "\
 file://CVE-2023-45287-pre2.patch \
 file://CVE-2023-45287-pre3.patch \
 file://CVE-2023-45287.patch \
+file://CVE-2023-45289.patch \
+file://CVE-2023-45290.patch \
+file://CVE-2024-24785.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
new file mode 100644
index 00..13d3510504
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
@@ -0,0 +1,121 @@
+From 20586c0dbe03d144f914155f879fa5ee287591a1 Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Thu, 11 Jan 2024 11:31:57 -0800
+Subject: [PATCH] [release-branch.go1.21] net/http, net/http/cookiejar: avoid
+ subdomain matches on IPv6 zones
+
+When deciding whether to forward cookies or sensitive headers
+across a redirect, do not attempt to interpret an IPv6 address
+as a domain name.
+
+Avoids a case where a maliciously-crafted redirect to an
+IPv6 address with a scoped addressing zone could be
+misinterpreted as a within-domain redirect. For example,
+we could interpret "::1%.www.example.com" as a subdomain
+of "www.example.com".
+
+Thanks to Juho Nurminen of Mattermost for reporting this issue.
+
+Fixes CVE-2023-45289
+Fixes #65385
+For #65065
+
+Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2131938
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Roland Shoemaker 
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2173775
+Reviewed-by: Carlos Amedee 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/569239
+Reviewed-by: Carlos Amedee 
+Auto-Submit: Michael Knyszek 
+TryBot-Bypass: Michael Knyszek 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1]
+CVE: CVE-2023-45289
+Signed-off-by: Vijay Anusuri 
+---
+ src/net/http/client.go |  6 ++
+ src/net/http/client_test.go|  1 +
+ src/net/http/cookiejar/jar.go  |  7 +++
+ src/net/http/cookiejar/jar_test.go | 10 ++
+ 4 files changed, 24 insertions(+)
+
+diff --git a/src/net/http/client.go b/src/net/http/client.go
+index a496f1c..2031834 100644
+--- a/src/net/http/client.go
 b/src/net/http/client.go
+@@ -973,6 +973,12 @@ func isDomainOrSubdomain(sub, parent string) bool {
+   if sub == parent {
+   return true
+   }
++  // If sub contains a :, it's probably an IPv6 address (and is 
definitely not a hostname).
++  // Don't check the suffix in this case, to avoid matching the contents 
of a IPv6 zone.
++  // For example, "::1%.www.example.com" is not a subdomain of 
"www.example.com".
++  if strings.ContainsAny(sub, ":%") {
++  return false
++  }
+   // If sub is "foo.example.com" and parent is "example.com",
+   // that means sub must end in "."+parent.
+   // Do it without allocating.
+diff --git a/src/net/http/client_test.go b/src/net/http/client_test.go
+index 2b4f53f..442fe35 100644
+--- a/src/net/http/client_test.go
 b/src/net/http/client_test.go
+@@ -1703,6 +1703,7 @@ func TestShouldCopyHeaderOnRedirect(t *testing.T) {
+   {"cookie2", "http://foo.com/;, "http://bar.com/;, false},
+   {"authorization", "http://foo.com/;, "http://bar.com/;, false},
+   {"www-authenticate", "http://foo.com/;, "http://bar.com/;, 
false},
++  {"authorization", "http://foo.com/;, 
"http://[::1%25.foo.com]/;, false},
+ 
+   // But subdomains should work:
+   {"www-authenticate", "http://foo.com/;, "http://foo.com/;, 
true},
+diff --git a/src/net/http/cookiejar/jar.go b/src/net/http/cookiejar/jar.go
+index 9f19917..18cbfc2 100644
+--- a/src/net/http/cookiejar/jar.go
 

[OE-core][dunfell 1/7] libtiff: backport Debian patch for CVE-2023-6277 & CVE-2023-52356

2024-04-02 Thread Steve Sakoman
From: Vijay Anusuri 

import patches from ubuntu to fix
 CVE-2023-6277
 CVE-2023-52356

Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/tiff/tree/debian/patches/?h=ubuntu%2Ffocal-security
Upstream commit
https://gitlab.com/libtiff/libtiff/-/commit/5320c9d89c054fa805d037d84c57da874470b01a
&
https://gitlab.com/libtiff/libtiff/-/commit/0b025324711213a75e38b52f7e7ba60235f108aa
&
https://gitlab.com/libtiff/libtiff/-/commit/de7bfd7d4377c266f81849579f696fa1ad5ba6c3
&
https://gitlab.com/libtiff/libtiff/-/commit/dbb825a8312f30e63a06c272010967d51af5c35a
&
https://gitlab.com/libtiff/libtiff/-/commit/51558511bdbbcffdce534db21dbaf5d54b31638a]

Signed-off-by: Vijay Anusuri 
Signed-off-by: Steve Sakoman 
---
 .../libtiff/files/CVE-2023-52356.patch|  53 +
 .../libtiff/files/CVE-2023-6277-1.patch   | 191 ++
 .../libtiff/files/CVE-2023-6277-2.patch   | 152 ++
 .../libtiff/files/CVE-2023-6277-3.patch   |  46 +
 .../libtiff/files/CVE-2023-6277-4.patch   |  94 +
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   5 +
 6 files changed, 541 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-52356.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-1.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-2.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-3.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-4.patch

diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2023-52356.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2023-52356.patch
new file mode 100644
index 00..1b651e6529
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2023-52356.patch
@@ -0,0 +1,53 @@
+[Ubuntu note: Backport of the following patch from upstream, with a few changes
+to match the current version of the file in the present Ubuntu release:
+ . using TIFFErrorExt instead of TIFFErrorExtR (the latter did not exist yet);
+-- Rodrigo Figueiredo Zaiden]
+
+Backport of:
+
+From 51558511bdbbcffdce534db21dbaf5d54b31638a Mon Sep 17 00:00:00 2001
+From: Even Rouault 
+Date: Tue, 31 Oct 2023 15:58:41 +0100
+Subject: [PATCH] TIFFReadRGBAStrip/TIFFReadRGBATile: add more validation of
+ col/row (fixes #622)
+
+Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/tiff/tree/debian/patches/CVE-2023-52356.patch?h=ubuntu/focal-security
+Upstream commit  
https://gitlab.com/libtiff/libtiff/-/commit/51558511bdbbcffdce534db21dbaf5d54b31638a]
+CVE: CVE-2023-52356
+Signed-off-by: Vijay Anusuri 
+---
+ libtiff/tif_getimage.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+
+--- tiff-4.1.0+git191117.orig/libtiff/tif_getimage.c
 tiff-4.1.0+git191117/libtiff/tif_getimage.c
+@@ -2926,6 +2926,13 @@ TIFFReadRGBAStripExt(TIFF* tif, uint32 r
+ }
+ 
+ if (TIFFRGBAImageOK(tif, emsg) && TIFFRGBAImageBegin(, tif, 
stop_on_error, emsg)) {
++if (row >= img.height)
++{
++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
++  "Invalid row passed to TIFFReadRGBAStrip().");
++TIFFRGBAImageEnd();
++return (0);
++}
+ 
+ img.row_offset = row;
+ img.col_offset = 0;
+@@ -3002,6 +3009,14 @@ TIFFReadRGBATileExt(TIFF* tif, uint32 co
+   return( 0 );
+ }
+ 
++if (col >= img.width || row >= img.height)
++{
++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
++  "Invalid row/col passed to TIFFReadRGBATile().");
++TIFFRGBAImageEnd();
++return (0);
++}
++
+ /*
+  * The TIFFRGBAImageGet() function doesn't allow us to get off the
+  * edge of the image, even to fill an otherwise valid tile.  So we
diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2023-6277-1.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2023-6277-1.patch
new file mode 100644
index 00..e955b3f2e4
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2023-6277-1.patch
@@ -0,0 +1,191 @@
+[Ubuntu note: Backport of the following patch from upstream, with a few changes
+to match the current version of the file in the present Ubuntu release:
+ . included inttypes.h header to support PRIu32 and PRIu64;
+ . using TIFFWarningExt instead of TIFFWarningExtR (the latter did not exist 
yet);
+ . using uint64 instead of uint64_t to preserve the current code usage;
+ . calling _TIFFfree(data) instead of _TIFFfreeExt(tif, data) (the latter did 
not exist yet);
+ . calls to the check size, that is the idea of the patch, were added before
+   _TIFFCheckMalloc and may note match the original patch methods;
+-- Rodrigo Figueiredo Zaiden]
+
+Backport of:
+
+From 5320c9d89c054fa805d037d84c57da874470b01a Mon Sep 17 00:00:00 2001
+From: Su Laus 
+Date: Tue, 31 Oct 2023 15:43:29 +
+Subject: [PATCH] Prevent some out-of-memory attacks
+

[OE-core][dunfell 0/7] Patch review

2024-04-02 Thread Steve Sakoman
Please review this set of changes for dunfell and have comments back by
end of day Thursday, April 4

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6757

The following changes since commit d0811b98fa3847dbbfcfe6a80694509bb29aaf9c:

  yocto-uninative: Update to 4.4 for glibc 2.39 (2024-03-18 11:44:32 -1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut

Steve Sakoman (2):
  tar: bump PR to deal with sstate corruption on autobuilder
  perf: bump PR to deal with sstate corruption on autobuilder

Vijay Anusuri (4):
  libtiff: backport Debian patch for CVE-2023-6277 & CVE-2023-52356
  go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785
  tar: Fix for CVE-2023-39804
  curl: backport Debian patch for CVE-2024-2398

virendra thakur (1):
  openssl: Fix CVE-2024-0727

 .../openssl/openssl/CVE-2024-0727.patch   | 122 
 .../openssl/openssl_1.1.1w.bb |   1 +
 meta/recipes-devtools/go/go-1.14.inc  |   3 +
 .../go/go-1.14/CVE-2023-45289.patch   | 121 
 .../go/go-1.14/CVE-2023-45290.patch   | 271 ++
 .../go/go-1.14/CVE-2024-24785.patch   | 197 +
 .../tar/tar/CVE-2023-39804.patch  |  64 +
 meta/recipes-extended/tar/tar_1.32.bb |   3 +
 meta/recipes-kernel/perf/perf.bb  |   2 +-
 .../libtiff/files/CVE-2023-52356.patch|  53 
 .../libtiff/files/CVE-2023-6277-1.patch   | 191 
 .../libtiff/files/CVE-2023-6277-2.patch   | 152 ++
 .../libtiff/files/CVE-2023-6277-3.patch   |  46 +++
 .../libtiff/files/CVE-2023-6277-4.patch   |  94 ++
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   5 +
 .../curl/curl/CVE-2024-2398.patch |  88 ++
 meta/recipes-support/curl/curl_7.69.1.bb  |   1 +
 17 files changed, 1413 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2024-0727.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45290.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2024-24785.patch
 create mode 100644 meta/recipes-extended/tar/tar/CVE-2023-39804.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-52356.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-1.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-2.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-3.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-6277-4.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2024-2398.patch

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197885): 
https://lists.openembedded.org/g/openembedded-core/message/197885
Mute This Topic: https://lists.openembedded.org/mt/105302356/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][PATCH] lttng-tools: fix rotation-destroy-flush test fails if no kernel module present

2024-04-02 Thread Xiangyu Chen
From: Xiangyu Chen 

lttng-tools supports testing the userspace application without kernel
module since oe-core commit e0d8494b, this is a fix that testcase
rotation-destroy-flush report LTTNG_ABORT_ON_ERROR when no lttng kernel
module present.

Fixes: e0d8494b (lttng-tools: skip kernel tests if no kernel modules present)

Signed-off-by: Xiangyu Chen 
---
 ...troy-flush-fix-session-daemon-abort-.patch | 56 +++
 .../lttng/lttng-tools_2.13.11.bb  |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch
new file mode 100644
index 00..3286dfb5c1
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch
@@ -0,0 +1,56 @@
+From 6b45c5f80d20e7bbf3d98c1fa17d2cf8716af3bb Mon Sep 17 00:00:00 2001
+From: Xiangyu Chen 
+Date: Mon, 25 Mar 2024 18:20:14 +0800
+Subject: [PATCH] Fix: rotation-destroy-flush: fix session daemon abort if no
+ kernel module present
+
+Testing rotation-destroy-flush when no lttng kernel modules present, it would
+be failed with error message:
+
+  Error: Unable to load required module lttng-ring-buffer-client-discard
+  not ok 1 - Start session daemon
+  Failed test 'Start session daemon'
+  not ok 2 - Create session rotation_destroy_flush in -o /tmp/tmp.test_rot ...
+  ...
+
+This because test script that sets the LTTNG_ABORT_ON_ERROR environment
+variable. It's this environment variable that causes the sessiond to handle the
+kernel module loading failure as an abort rather than a warning.
+
+Using "check_skip_kernel_test" to detect whether the kernel module fails to
+load is expected or not. If the failure is expected, the script won't set that
+environment variable any more.
+
+Fixes: 3a174400
+("tests:add check_skip_kernel_test to check root user and lttng kernel 
modules")
+
+Upstream-Status: Submitted [https://review.lttng.org/c/lttng-tools/+/12155]
+
+Change-Id: I371e9ba717613e2940186f710cf3cccd35baed6c
+Signed-off-by: Xiangyu Chen 
+---
+ .../ust/rotation-destroy-flush/test_rotation_destroy_flush  | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git 
a/tests/regression/ust/rotation-destroy-flush/test_rotation_destroy_flush 
b/tests/regression/ust/rotation-destroy-flush/test_rotation_destroy_flush
+index 669bcbc43..64161768f 100755
+--- a/tests/regression/ust/rotation-destroy-flush/test_rotation_destroy_flush
 b/tests/regression/ust/rotation-destroy-flush/test_rotation_destroy_flush
+@@ -23,11 +23,11 @@ SIZE_LIMIT=$PAGE_SIZE
+ NR_ITER=10
+ NUM_TESTS=$((15*$NR_ITER))
+ 
+-# Ensure the daemons invoke abort on error.
+-export LTTNG_ABORT_ON_ERROR=1
+-
+ source $TESTDIR/utils/utils.sh
+ 
++# Ensure the daemons invoke abort on error.
++check_skip_kernel_test || export LTTNG_ABORT_ON_ERROR=1
++
+ # MUST set TESTDIR before calling those functions
+ function run_app()
+ {
+-- 
+2.25.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
index 08144e271c..f6abd9e11a 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
@@ -38,6 +38,7 @@ SRC_URI = 
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://disable-tests.patch \
file://0001-compat-Define-off64_t-as-off_t-on-linux.patch \

file://0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch \
+   
file://0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch \
"
 
 SRC_URI[sha256sum] = 
"ac5baeef9fa690936b1ca01ecd1742da762c2c08511ff1b4e923938d94d0f979"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197884): 
https://lists.openembedded.org/g/openembedded-core/message/197884
Mute This Topic: https://lists.openembedded.org/mt/105301969/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] New mailing list for layer patches

2024-04-02 Thread Peter Kjellerstedt
> -Original Message-
> From: yo...@lists.yoctoproject.org  On
> Behalf Of Ross Burton
> Sent: den 28 mars 2024 15:37
> To: openembedded-architecture  architect...@lists.openembedded.org>; Yocto-mailing-list
> ; OE-core  c...@lists.openembedded.org>
> Subject: [yocto] New mailing list for layer patches
> 
> Hi,
> 
> At the moment if a layer doesn’t have enough volume to justify a dedicated
> mailing list for patches (see, for example, meta-
> a...@lists.yoctoproject.org ) then
> the convention is that the patches can be sent to
> yo...@lists.yoctoproject.org .
> 
> However, that’s also the list that we encourage users of Yocto to use for
> help, so the list has a mix of patches for various layers and people
> asking for help, which isn’t ideal: users who want help don’t want to be
> flooded with patches for layers they’re not using, layer maintainers may
> not want to see the requests for help, and people who want the status
> reports have to receive patches and support.
> 
> The Yocto TSC has been discussing this, and as a solution to this we’ve
> just created a new mailing list: yocto-patc...@lists.yoctoproject.org
> .  This list is specifically
> for Yocto-related projects which don’t have their own mailing list or
> other patch submission process.   We ask that all layers currently using
> yocto@ for patches move to yocto-patches@, so that yocto@ can be used
> purely for discussion and other non-patch related subjects.
> 
> Many thanks,
> Ross
> Yocto TSC member

To whoever is responsible for updating 
https://www.yoctoproject.org/community/mailing-lists/: the links for the 
two new lists both refer to yocto-announce rather than yocto-status and 
yocto-patches.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197883): 
https://lists.openembedded.org/g/openembedded-core/message/197883
Mute This Topic: https://lists.openembedded.org/mt/105197687/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH v2 1/3] binutils-cross-canadian: add gprofng package as runtime dependency

2024-04-02 Thread Alexandre Belloni via lists.openembedded.org
I believe this causes these failures:

https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/8798/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/9202/steps/12/logs/stdio

On 29/03/2024 07:55:05-0700, Sadineni, Harish via lists.openembedded.org wrote:
> From: Harish Sadineni 
> 
> In SDK, while running "x86_64-poky-linux-gp-collect-app ./exe" fails to 
> create 'test.1.er' due to missing gprofng configure file in sysconfdir and 
> aborting with below error while generating the profiling data.
> - configuration error: can not find libgp-collector.so. run aborted
> 
> Signed-off-by: Harish Sadineni 
> ---
>  meta/recipes-devtools/binutils/binutils-cross-canadian.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc 
> b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> index 62ebb3f5bc..7f2699089e 100644
> --- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> @@ -30,3 +30,4 @@ do_install () {
>  }
>  
>  BBCLASSEXTEND = ""
> +RDEPENDS:${PN} = "nativesdk-gprofng"
> -- 
> 2.43.0
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197882): 
https://lists.openembedded.org/g/openembedded-core/message/197882
Mute This Topic: https://lists.openembedded.org/mt/105216924/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH v2] recipeutils: use UPSTREAM_CHECK_URI in get_recipe_upstream_version

2024-04-02 Thread Jon Mason
Depends on your definition of "does not break".  Does it run without
throwing errors?  Yes.  Does it give the same output?  No.
Originally, I only tested on a couple of recipes, and not the world.
So, I admit to not running this test prior to you asking.

This output is very noisy.  So, it is difficult to get an accurate
idea of whether the differences are regressions or not.  Also, the
output of the individual recipes and versions is not outputted in the
same order.  Looking at the output (after a rough sort), I do see
different values for some.  Like:
-acpica20230628UNKNOWN Ross Burton

+acpica20230628KNOWN_BROKENRoss Burton

-gnuplot   5.4.3   6.0.0   None
+gnuplot   5.4.3   UNKNOWN_BROKEN  None
-icu   74-174-2Alexander
Kanavin 
+icu   74-174.1Alexander
Kanavin 

Let me poke around with this output to try to make more sense of it
and see if there are real regressions or if it is something else.

Thanks,
Jon


On Tue, Apr 2, 2024 at 2:22 PM Alexander Kanavin  wrote:
>
> Have you confirmed that this does not break 'devtool check-upgrade-status' ?
>
> Alex
>
> On Tue, 2 Apr 2024 at 20:09, Jon Mason  wrote:
> >
> > Currently, get_recipe_upstream_version blindly takes the first entry in
> > SRC_URI to see if the recipe is at the latest version.  If
> > UPSTREAM_CHECK_URI is specified in a recipe, it is probably what should
> > be used to check for the latest version.  Use that as the first check,
> > otherwise default back to the first entry in SRC_URI.
> >
> > wget was doing it's own check for UPSTREAM_CHECK_URI.  Removing this in
> > favor of the common one now being done in recipeutils.py.
> >
> > Signed-off-by: Jon Mason 
> > ---
> >  bitbake/lib/bb/fetch2/wget.py | 37 +++
> >  meta/lib/oe/recipeutils.py|  9 +++--
> >  2 files changed, 23 insertions(+), 23 deletions(-)
> >
> > diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
> > index dc025800e659..0342f895646d 100644
> > --- a/bitbake/lib/bb/fetch2/wget.py
> > +++ b/bitbake/lib/bb/fetch2/wget.py
> > @@ -629,27 +629,22 @@ class Wget(FetchMethod):
> >  return ('', '')
> >  bb.debug(3, "latest_versionstring, regex: %s" % 
> > (package_regex.pattern))
> >
> > -uri = ""
> > -regex_uri = d.getVar("UPSTREAM_CHECK_URI")
> > -if not regex_uri:
> > -path = ud.path.split(package)[0]
> > -
> > -# search for version matches on folders inside the path, like:
> > -# "5.7" in 
> > http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
> > -dirver_regex = 
> > re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
> > -m = dirver_regex.findall(path)
> > -if m:
> > -pn = d.getVar('PN')
> > -dirver = m[-1][0]
> > -
> > -dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
> > -if not dirver_pn_regex.search(dirver):
> > -return (self._check_latest_version_by_dir(dirver,
> > -package, package_regex, current_version, ud, d), 
> > '')
> > -
> > -uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, 
> > ud.pswd, {}])
> > -else:
> > -uri = regex_uri
> > +path = ud.path.split(package)[0]
> > +
> > +# search for version matches on folders inside the path, like:
> > +# "5.7" in 
> > http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
> > +dirver_regex = 
> > re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
> > +m = dirver_regex.findall(path)
> > +if m:
> > +pn = d.getVar('PN')
> > +dirver = m[-1][0]
> > +
> > +dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
> > +if not dirver_pn_regex.search(dirver):
> > +return (self._check_latest_version_by_dir(dirver,
> > +package, package_regex, current_version, ud, d), '')
> > +
> > +uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, 
> > ud.pswd, {}])
> >
> >  return (self._check_latest_version(uri, package, package_regex,
> >  current_version, ud, d), '')
> > diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> > index de1fbdd3a8c8..a42609060cd9 100644
> > --- a/meta/lib/oe/recipeutils.py
> > +++ b/meta/lib/oe/recipeutils.py
> > @@ -1041,8 +1041,13 @@ def get_recipe_upstream_version(rd):
> >  ru['datetime'] = datetime.now()
> >  return ru
> >
> > -# XXX: we suppose that the first entry points to the upstream sources
> > -src_uri = src_uris.split()[0]
> > +# If UPSTREAM_CHECK_URI is specified, assume it is correct and use
> > +# it.  Otherwise, use the first SRC_URI 

Re: [OE-core] [PATCH v2] gstreamer1.0-plugins-good: Provide Qt6 option for qmlgl

2024-04-02 Thread Alexander Kanavin
On Tue, 2 Apr 2024 at 21:20, Andreas Cord-Landwehr  wrote:
> https://github.com/mesonbuild/meson/issues/13018
>
> Regarding the way meson finds native binaries, do you have an example how this
> is done in Yocto specifically how meson is pointed to the recipe-sysroot-
> native? All I could find was pkg-config but that has a special native pc file 
> as
> far as I see.

Slightly wrong upstream, I think. Meson already has 'native' keyword
in various functions, for example dependency():
https://mesonbuild.com/Reference-manual_functions.html#dependency
Setting that to true will result in meson calling native pkg-config
for obtaining information, and that would point to the native sysroot.

So gstreamer needs to be fixed to use native: true for finding
binaries it needs to execute. Did you look into how it looks for them
in its meson.build files?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197880): 
https://lists.openembedded.org/g/openembedded-core/message/197880
Mute This Topic: https://lists.openembedded.org/mt/105259530/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH v2] gstreamer1.0-plugins-good: Provide Qt6 option for qmlgl

2024-04-02 Thread Andreas Cord-Landwehr
Hi Alex, thanks for your answer! I raised this topic also upstream in

https://github.com/mesonbuild/meson/issues/13018

Regarding the way meson finds native binaries, do you have an example how this 
is done in Yocto specifically how meson is pointed to the recipe-sysroot-
native? All I could find was pkg-config but that has a special native pc file 
as 
far as I see.

Cheers,
Andreas

On Tuesday, April 2, 2024 8:26:48 PM CEST Alexander Kanavin wrote:
> meson does have a way to specify whether native pkg-config should be
> used (defaulting to cross), so I think this should rather be fixed in
> gstreamer source, particularly its meson files?
> 
> Alex
> 
> On Mon, 1 Apr 2024 at 09:14, Andreas Cord-Landwehr  
wrote:
> > Introduce PACKAGECONFIG option for Qt6 and provide meson cross-build
> > file that helps meson to locate qt native binaries.
> > 
> > Qt provides pkg-config files since Qt6.3+, but those files are not
> > sufficient to detect native tools that are located in the
> > recipe-sysroot-native location, because pkg-config does not know about
> > the location of them. Thus, introduce a helper config that points mesons
> > to those binaries.
> > 
> > Signed-off-by: Andreas Cord-Landwehr 
> > ---
> > 
> >  .../gstreamer1.0-plugins-good_1.22.11.bb   | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git
> > a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> > index edd8609b7c..3b95bd6e46 100644
> > ---
> > a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> > +++
> > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> > @@ -12,6 +12,17 @@ SRC_URI[sha256sum] =
> > "6ddd032381827d31820540735f0004b429436b0bdac19aaeab44fa22fa> 
> >  S = "${WORKDIR}/gst-plugins-good-${PV}"
> > 
> > +do_write_config:append() {
> > +cat >${WORKDIR}/meson-qt6.cross < > +[binaries]
> > +qmake = '${STAGING_BINDIR_NATIVE}/qmake'
> > +moc = '${STAGING_DIR_NATIVE}/usr/libexec/moc'
> > +rcc = '${STAGING_DIR_NATIVE}/usr/libexec/rcc'
> > +uic = '${STAGING_DIR_NATIVE}/usr/libexec/uic'
> > +lrelease = '${STAGING_BINDIR_NATIVE}/lrelease'
> > +EOF
> > +}
> > +
> > 
> >  LICENSE = "LGPL-2.1-or-later"
> >  LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
> >  
> >  file://gst/replaygain/rganalysis.c;beginline=1;endlin
> >  e=23;md5=b60ebefd5b2f5a8e0cab6bfee391a5fe"> 
> > @@ -35,7 +46,7 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxfixes
> > libxdamage"> 
> >  X11ENABLEOPTS = "-Dximagesrc=enabled -Dximagesrc-xshm=enabled
> >  -Dximagesrc-xfixes=enabled -Dximagesrc-xdamage=enabled" X11DISABLEOPTS =
> >  "-Dximagesrc=disabled -Dximagesrc-xshm=disabled
> >  -Dximagesrc-xfixes=disabled -Dximagesrc-xdamage=disabled"> 
> > -QT5WAYLANDDEPENDS = "${@bb.utils.contains("DISTRO_FEATURES", "wayland",
> > "qtwayland", "", d)}" +QTWAYLANDDEPENDS =
> > "${@bb.utils.contains("DISTRO_FEATURES", "wayland", "qtwayland", "", d)}"> 
> >  PACKAGECONFIG[asm]= "-Dasm=enabled,-Dasm=disabled,nasm-native"
> >  PACKAGECONFIG[bz2]= "-Dbz2=enabled,-Dbz2=disabled,bzip2"
> > 
> > @@ -52,7 +63,8 @@ PACKAGECONFIG[libpng] =
> > "-Dpng=enabled,-Dpng=disabled,libpng"> 
> >  PACKAGECONFIG[libv4l2]=
> >  "-Dv4l2-libv4l2=enabled,-Dv4l2-libv4l2=disabled,v4l-utils"
> >  PACKAGECONFIG[mpg123] = "-Dmpg123=enabled,-Dmpg123=disabled,mpg123"
> >  PACKAGECONFIG[pulseaudio] =
> >  "-Dpulse=enabled,-Dpulse=disabled,pulseaudio"> 
> > -PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase
> > qtdeclarative qtbase-native ${QT5WAYLANDDEPENDS}" +PACKAGECONFIG[qt5]
> >= "-Dqt5=enabled,-Dqt5=disabled,qtbase qtdeclarative qtbase-native
> > ${QTWAYLANDDEPENDS}" +PACKAGECONFIG[qt6]=
> > "-Dqt6=enabled,-Dqt6=disabled,qtbase qtdeclarative qtbase-native
> > qttools-native ${QTWAYLANDDEPENDS}"> 
> >  PACKAGECONFIG[soup2]  = "-Dsoup=enabled,,libsoup-2.4,,,soup3"
> >  PACKAGECONFIG[soup3]  = "-Dsoup=enabled,,libsoup,,,soup2"
> >  PACKAGECONFIG[speex]  = "-Dspeex=enabled,-Dspeex=disabled,speex"
> > 
> > @@ -78,4 +90,6 @@ EXTRA_OEMESON += " \
> > 
> >  -Dwaveform=disabled \
> >  
> >  "
> > 
> > +MESON_CROSS_FILE:class-target:append =
> > "${@bb.utils.contains('PACKAGECONFIG', 'qt6', ' --cross
> > ${WORKDIR}/meson-qt6.cross', '', d)}" +
> > 
> >  FILES:${PN}-equalizer += "${datadir}/gstreamer-1.0/presets/*.prs"
> > 
> > --
> > 2.40.1
> > 
> > 
> > 


signature.asc
Description: This is a digitally signed message part.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197879): 
https://lists.openembedded.org/g/openembedded-core/message/197879
Mute This Topic: https://lists.openembedded.org/mt/105259530/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 

Re: [OE-core] [PATCH v2] gstreamer1.0-plugins-good: Provide Qt6 option for qmlgl

2024-04-02 Thread Alexander Kanavin
meson does have a way to specify whether native pkg-config should be
used (defaulting to cross), so I think this should rather be fixed in
gstreamer source, particularly its meson files?

Alex

On Mon, 1 Apr 2024 at 09:14, Andreas Cord-Landwehr  wrote:
>
> Introduce PACKAGECONFIG option for Qt6 and provide meson cross-build
> file that helps meson to locate qt native binaries.
>
> Qt provides pkg-config files since Qt6.3+, but those files are not
> sufficient to detect native tools that are located in the
> recipe-sysroot-native location, because pkg-config does not know about
> the location of them. Thus, introduce a helper config that points mesons
> to those binaries.
>
> Signed-off-by: Andreas Cord-Landwehr 
> ---
>  .../gstreamer1.0-plugins-good_1.22.11.bb   | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> index edd8609b7c..3b95bd6e46 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.11.bb
> @@ -12,6 +12,17 @@ SRC_URI[sha256sum] = 
> "6ddd032381827d31820540735f0004b429436b0bdac19aaeab44fa22fa
>
>  S = "${WORKDIR}/gst-plugins-good-${PV}"
>
> +do_write_config:append() {
> +cat >${WORKDIR}/meson-qt6.cross < +[binaries]
> +qmake = '${STAGING_BINDIR_NATIVE}/qmake'
> +moc = '${STAGING_DIR_NATIVE}/usr/libexec/moc'
> +rcc = '${STAGING_DIR_NATIVE}/usr/libexec/rcc'
> +uic = '${STAGING_DIR_NATIVE}/usr/libexec/uic'
> +lrelease = '${STAGING_BINDIR_NATIVE}/lrelease'
> +EOF
> +}
> +
>  LICENSE = "LGPL-2.1-or-later"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
>  
> file://gst/replaygain/rganalysis.c;beginline=1;endline=23;md5=b60ebefd5b2f5a8e0cab6bfee391a5fe"
> @@ -35,7 +46,7 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxfixes 
> libxdamage"
>  X11ENABLEOPTS = "-Dximagesrc=enabled -Dximagesrc-xshm=enabled 
> -Dximagesrc-xfixes=enabled -Dximagesrc-xdamage=enabled"
>  X11DISABLEOPTS = "-Dximagesrc=disabled -Dximagesrc-xshm=disabled 
> -Dximagesrc-xfixes=disabled -Dximagesrc-xdamage=disabled"
>
> -QT5WAYLANDDEPENDS = "${@bb.utils.contains("DISTRO_FEATURES", "wayland", 
> "qtwayland", "", d)}"
> +QTWAYLANDDEPENDS = "${@bb.utils.contains("DISTRO_FEATURES", "wayland", 
> "qtwayland", "", d)}"
>
>  PACKAGECONFIG[asm]= "-Dasm=enabled,-Dasm=disabled,nasm-native"
>  PACKAGECONFIG[bz2]= "-Dbz2=enabled,-Dbz2=disabled,bzip2"
> @@ -52,7 +63,8 @@ PACKAGECONFIG[libpng] = 
> "-Dpng=enabled,-Dpng=disabled,libpng"
>  PACKAGECONFIG[libv4l2]= 
> "-Dv4l2-libv4l2=enabled,-Dv4l2-libv4l2=disabled,v4l-utils"
>  PACKAGECONFIG[mpg123] = "-Dmpg123=enabled,-Dmpg123=disabled,mpg123"
>  PACKAGECONFIG[pulseaudio] = "-Dpulse=enabled,-Dpulse=disabled,pulseaudio"
> -PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase 
> qtdeclarative qtbase-native ${QT5WAYLANDDEPENDS}"
> +PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase 
> qtdeclarative qtbase-native ${QTWAYLANDDEPENDS}"
> +PACKAGECONFIG[qt6]= "-Dqt6=enabled,-Dqt6=disabled,qtbase 
> qtdeclarative qtbase-native qttools-native ${QTWAYLANDDEPENDS}"
>  PACKAGECONFIG[soup2]  = "-Dsoup=enabled,,libsoup-2.4,,,soup3"
>  PACKAGECONFIG[soup3]  = "-Dsoup=enabled,,libsoup,,,soup2"
>  PACKAGECONFIG[speex]  = "-Dspeex=enabled,-Dspeex=disabled,speex"
> @@ -78,4 +90,6 @@ EXTRA_OEMESON += " \
>  -Dwaveform=disabled \
>  "
>
> +MESON_CROSS_FILE:class-target:append = 
> "${@bb.utils.contains('PACKAGECONFIG', 'qt6', ' --cross 
> ${WORKDIR}/meson-qt6.cross', '', d)}"
> +
>  FILES:${PN}-equalizer += "${datadir}/gstreamer-1.0/presets/*.prs"
> --
> 2.40.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197878): 
https://lists.openembedded.org/g/openembedded-core/message/197878
Mute This Topic: https://lists.openembedded.org/mt/105259530/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH v2] recipeutils: use UPSTREAM_CHECK_URI in get_recipe_upstream_version

2024-04-02 Thread Alexander Kanavin
Have you confirmed that this does not break 'devtool check-upgrade-status' ?

Alex

On Tue, 2 Apr 2024 at 20:09, Jon Mason  wrote:
>
> Currently, get_recipe_upstream_version blindly takes the first entry in
> SRC_URI to see if the recipe is at the latest version.  If
> UPSTREAM_CHECK_URI is specified in a recipe, it is probably what should
> be used to check for the latest version.  Use that as the first check,
> otherwise default back to the first entry in SRC_URI.
>
> wget was doing it's own check for UPSTREAM_CHECK_URI.  Removing this in
> favor of the common one now being done in recipeutils.py.
>
> Signed-off-by: Jon Mason 
> ---
>  bitbake/lib/bb/fetch2/wget.py | 37 +++
>  meta/lib/oe/recipeutils.py|  9 +++--
>  2 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
> index dc025800e659..0342f895646d 100644
> --- a/bitbake/lib/bb/fetch2/wget.py
> +++ b/bitbake/lib/bb/fetch2/wget.py
> @@ -629,27 +629,22 @@ class Wget(FetchMethod):
>  return ('', '')
>  bb.debug(3, "latest_versionstring, regex: %s" % 
> (package_regex.pattern))
>
> -uri = ""
> -regex_uri = d.getVar("UPSTREAM_CHECK_URI")
> -if not regex_uri:
> -path = ud.path.split(package)[0]
> -
> -# search for version matches on folders inside the path, like:
> -# "5.7" in 
> http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
> -dirver_regex = 
> re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
> -m = dirver_regex.findall(path)
> -if m:
> -pn = d.getVar('PN')
> -dirver = m[-1][0]
> -
> -dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
> -if not dirver_pn_regex.search(dirver):
> -return (self._check_latest_version_by_dir(dirver,
> -package, package_regex, current_version, ud, d), '')
> -
> -uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, 
> ud.pswd, {}])
> -else:
> -uri = regex_uri
> +path = ud.path.split(package)[0]
> +
> +# search for version matches on folders inside the path, like:
> +# "5.7" in 
> http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
> +dirver_regex = 
> re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
> +m = dirver_regex.findall(path)
> +if m:
> +pn = d.getVar('PN')
> +dirver = m[-1][0]
> +
> +dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
> +if not dirver_pn_regex.search(dirver):
> +return (self._check_latest_version_by_dir(dirver,
> +package, package_regex, current_version, ud, d), '')
> +
> +uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, ud.pswd, 
> {}])
>
>  return (self._check_latest_version(uri, package, package_regex,
>  current_version, ud, d), '')
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> index de1fbdd3a8c8..a42609060cd9 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1041,8 +1041,13 @@ def get_recipe_upstream_version(rd):
>  ru['datetime'] = datetime.now()
>  return ru
>
> -# XXX: we suppose that the first entry points to the upstream sources
> -src_uri = src_uris.split()[0]
> +# If UPSTREAM_CHECK_URI is specified, assume it is correct and use
> +# it.  Otherwise, use the first SRC_URI specified to determine the
> +# latest version.
> +if rd.getVar('UPSTREAM_CHECK_URI'):
> +src_uri = str(rd.getVar('UPSTREAM_CHECK_URI'))
> +else:
> +src_uri = src_uris.split()[0]
>  uri_type, _, _, _, _, _ =  decodeurl(src_uri)
>
>  (pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
> --
> 2.30.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197877): 
https://lists.openembedded.org/g/openembedded-core/message/197877
Mute This Topic: https://lists.openembedded.org/mt/105293221/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2] recipeutils: use UPSTREAM_CHECK_URI in get_recipe_upstream_version

2024-04-02 Thread Jon Mason
Currently, get_recipe_upstream_version blindly takes the first entry in
SRC_URI to see if the recipe is at the latest version.  If
UPSTREAM_CHECK_URI is specified in a recipe, it is probably what should
be used to check for the latest version.  Use that as the first check,
otherwise default back to the first entry in SRC_URI.

wget was doing it's own check for UPSTREAM_CHECK_URI.  Removing this in
favor of the common one now being done in recipeutils.py.

Signed-off-by: Jon Mason 
---
 bitbake/lib/bb/fetch2/wget.py | 37 +++
 meta/lib/oe/recipeutils.py|  9 +++--
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
index dc025800e659..0342f895646d 100644
--- a/bitbake/lib/bb/fetch2/wget.py
+++ b/bitbake/lib/bb/fetch2/wget.py
@@ -629,27 +629,22 @@ class Wget(FetchMethod):
 return ('', '')
 bb.debug(3, "latest_versionstring, regex: %s" % 
(package_regex.pattern))
 
-uri = ""
-regex_uri = d.getVar("UPSTREAM_CHECK_URI")
-if not regex_uri:
-path = ud.path.split(package)[0]
-
-# search for version matches on folders inside the path, like:
-# "5.7" in 
http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
-dirver_regex = 
re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
-m = dirver_regex.findall(path)
-if m:
-pn = d.getVar('PN')
-dirver = m[-1][0]
-
-dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
-if not dirver_pn_regex.search(dirver):
-return (self._check_latest_version_by_dir(dirver,
-package, package_regex, current_version, ud, d), '')
-
-uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, 
ud.pswd, {}])
-else:
-uri = regex_uri
+path = ud.path.split(package)[0]
+
+# search for version matches on folders inside the path, like:
+# "5.7" in 
http://download.gnome.org/sources/${PN}/5.7/${PN}-${PV}.tar.gz
+dirver_regex = re.compile(r"(?P[^/]*(\d+\.)*\d+([-_]r\d+)*)/")
+m = dirver_regex.findall(path)
+if m:
+pn = d.getVar('PN')
+dirver = m[-1][0]
+
+dirver_pn_regex = re.compile(r"%s\d?" % (re.escape(pn)))
+if not dirver_pn_regex.search(dirver):
+return (self._check_latest_version_by_dir(dirver,
+package, package_regex, current_version, ud, d), '')
+
+uri = bb.fetch.encodeurl([ud.type, ud.host, path, ud.user, ud.pswd, 
{}])
 
 return (self._check_latest_version(uri, package, package_regex,
 current_version, ud, d), '')
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index de1fbdd3a8c8..a42609060cd9 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1041,8 +1041,13 @@ def get_recipe_upstream_version(rd):
 ru['datetime'] = datetime.now()
 return ru
 
-# XXX: we suppose that the first entry points to the upstream sources
-src_uri = src_uris.split()[0]
+# If UPSTREAM_CHECK_URI is specified, assume it is correct and use
+# it.  Otherwise, use the first SRC_URI specified to determine the
+# latest version.
+if rd.getVar('UPSTREAM_CHECK_URI'):
+src_uri = str(rd.getVar('UPSTREAM_CHECK_URI'))
+else:
+src_uri = src_uris.split()[0]
 uri_type, _, _, _, _, _ =  decodeurl(src_uri)
 
 (pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197876): 
https://lists.openembedded.org/g/openembedded-core/message/197876
Mute This Topic: https://lists.openembedded.org/mt/105293221/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] recipeutils: use UPSTREAM_CHECK_URI in get_recipe_upstream_version

2024-04-02 Thread Jon Mason
On Thu, Mar 28, 2024 at 11:54 AM Alexander Kanavin
 wrote:
>
> Unfortunately this isn't correct either. UPSTREAM_CHECK_URI is already
> checked by the wget fetcher to override the default (which is first
> entry in SRC_URI), so if you need it in other fetchers (e.g git), you
> should either add support for it there as well, or remove the code
> from wget fetcher at the same time. Otherwise, this change will make
> things very inconsistent and confusing.

Since you can specify a UPSTREAM_CHECK_URI that is a different fetch
methodology (e.g, git, cvs, wget, etc) than the SRC_URI now, it is
already inconsistent.  Performing the check for UPSTREAM_CHECK_URI
should be done in the get_upstream_version, so it can then use
whatever fetch methodology is specified.  So, I think it best to
remove the logic in wget.

I'll do a v2 to make the above change.

Thank you for taking the time to review my patch, and providing guidance.

Thanks,
Jon

> Alex
>
> On Thu, 28 Mar 2024 at 16:32, Jon Mason  wrote:
> >
> > Currently, get_recipe_upstream_version blindly takes the first entry in
> > SRC_URI to see if the recipe is at the latest version.  If
> > UPSTREAM_CHECK_URI is specified in a recipe, it is probably what should
> > be used to check for the latest version.  Use that as the first check,
> > otherwise default back to the first entry in SRC_URI.
> >
> > Signed-off-by: Jon Mason 
> > ---
> >  meta/lib/oe/recipeutils.py | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> > index de1fbdd3a8c8..a42609060cd9 100644
> > --- a/meta/lib/oe/recipeutils.py
> > +++ b/meta/lib/oe/recipeutils.py
> > @@ -1041,8 +1041,13 @@ def get_recipe_upstream_version(rd):
> >  ru['datetime'] = datetime.now()
> >  return ru
> >
> > -# XXX: we suppose that the first entry points to the upstream sources
> > -src_uri = src_uris.split()[0]
> > +# If UPSTREAM_CHECK_URI is specified, assume it is correct and use
> > +# it.  Otherwise, use the first SRC_URI specified to determine the
> > +# latest version.
> > +if rd.getVar('UPSTREAM_CHECK_URI'):
> > +src_uri = str(rd.getVar('UPSTREAM_CHECK_URI'))
> > +else:
> > +src_uri = src_uris.split()[0]
> >  uri_type, _, _, _, _, _ =  decodeurl(src_uri)
> >
> >  (pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
> > --
> > 2.30.2
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197875): 
https://lists.openembedded.org/g/openembedded-core/message/197875
Mute This Topic: https://lists.openembedded.org/mt/105198896/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core][kirkstone][PATCH 1/1] qemu: fix CVE-2023-3019

2024-04-02 Thread Steve Sakoman
I'm getting oe-selftest failures with this patch:

https://errors.yoctoproject.org/Errors/Details/761408/

"Failed: qemux86 does not shutdown within timeout(120)"

Steve

On Fri, Mar 29, 2024 at 12:38 AM Urade, Yogita via
lists.openembedded.org
 wrote:
>
> From: Yogita Urade 
>
> A DMA reentrancy issue leading to a use-after-free error was
> found in the e1000e NIC emulation code in QEMU. This issue
> could allow a privileged guest user to crash the QEMU process
> on the host, resulting in a denial of service.
>
> Fix indent issue in qemu.inc file
>
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2023-3019
>
> Signed-off-by: Yogita Urade 
> ---
>  meta/recipes-devtools/qemu/qemu.inc   |  19 +-
>  .../qemu/qemu/CVE-2023-3019-0001.patch| 135 
>  .../qemu/qemu/CVE-2023-3019-0002.patch| 610 ++
>  .../qemu/qemu/CVE-2023-3019-0003.patch|  88 +++
>  4 files changed, 844 insertions(+), 8 deletions(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0001.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0002.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0003.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index ad6b310137..08ce72546d 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -97,17 +97,20 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> file://CVE-2023-3301.patch \
> file://CVE-2023-3255.patch \
> file://CVE-2023-2861.patch \
> -  file://CVE-2020-14394.patch \
> -  file://CVE-2023-3354.patch \
> -  file://CVE-2023-3180.patch \
> -  file://CVE-2021-3638.patch \
> -  file://CVE-2023-1544.patch \
> -  file://CVE-2023-5088.patch \
> -  file://CVE-2024-24474.patch \
> -  file://CVE-2023-6693.patch \
> +   file://CVE-2020-14394.patch \
> +   file://CVE-2023-3354.patch \
> +   file://CVE-2023-3180.patch \
> +   file://CVE-2021-3638.patch \
> +   file://CVE-2023-1544.patch \
> +   file://CVE-2023-5088.patch \
> +   file://CVE-2024-24474.patch \
> +   file://CVE-2023-6693.patch \
> 
> file://scsi-disk-allow-MODE-SELECT-block-desriptor-to-set-the-block-size.patch
>  \
> 
> file://scsi-disk-ensure-block-size-is-non-zero-and-changes-limited-to-bits-8-15.patch
>  \
> file://CVE-2023-42467.patch \
> +   file://CVE-2023-3019-0001.patch \
> +   file://CVE-2023-3019-0002.patch \
> +   file://CVE-2023-3019-0003.patch \
> "
>  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>
> diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0001.patch 
> b/meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0001.patch
> new file mode 100644
> index 00..c1ef645eaf
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-3019-0001.patch
> @@ -0,0 +1,135 @@
> +From a2e1753b8054344f32cf94f31c6399a58794a380 Mon Sep 17 00:00:00 2001
> +From: Alexander Bulekov 
> +Date: Wed, 27 Mar 2024 09:41:44 +
> +Subject: [PATCH] memory: prevent dma-reentracy issues
> +
> +Add a flag to the DeviceState, when a device is engaged in PIO/MMIO/DMA.
> +This flag is set/checked prior to calling a device's MemoryRegion
> +handlers, and set when device code initiates DMA.  The purpose of this
> +flag is to prevent two types of DMA-based reentrancy issues:
> +
> +1.) mmio -> dma -> mmio case
> +2.) bh -> dma write -> mmio case
> +
> +These issues have led to problems such as stack-exhaustion and
> +use-after-frees.
> +
> +Summary of the problem from Peter Maydell:
> +https://lore.kernel.org/qemu-devel/cafeaca_23vc7he3iam-jva6w38lk4hjowae5kcknhprd5fp...@mail.gmail.com
> +
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/62
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/540
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/541
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/556
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/557
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/827
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1282
> +Resolves: CVE-2023-0330
> +
> +Signed-off-by: Alexander Bulekov 
> +Reviewed-by: Thomas Huth 
> +Message-Id: <20230427211013.2994127-2-alx...@bu.edu>
> +[thuth: Replace warn_report() with warn_report_once()]
> +Signed-off-by: Thomas Huth 
> +
> +CVE: CVE-2023-3019
> +Upstream-Status: Backport 
> [https://github.com/qemu/qemu/commit/a2e1753b8054344f32cf94f31c6399a58794a380]
> +
> +Signed-off-by: Yogita Urade 
> +---
> + include/exec/memory.h  |  5 +
> + include/hw/qdev-core.h |  7 +++
> + softmmu/memory.c   | 16 
> + 3 files changed, 28 insertions(+)
> +
> +diff --git a/include/exec/memory.h b/include/exec/memory.h
> +index 

Re: [OE-core] [PATCH] glibc: Fix stale qemu processes left after glibc oe-selftest

2024-04-02 Thread Khem Raj
On Tue, Apr 2, 2024 at 7:29 AM Richard Purdie
 wrote:
>
> On Tue, 2024-04-02 at 12:45 +0530, Shinde, Yash via
> lists.openembedded.org wrote:
> >  On 02-04-2024 01:28, Khem Raj wrote:
> >  it would be better to disable them just for architectures where it
> > > fails since it seems to be a workaround, it would be good to keep
> > > it
> > > as small as possible
> > >
> >  Initially, we implemented the changes to handle only for
> > architectures where it fails and reviewed it with Richard in a
> > meeting,
> >  but it was decided to skip the test cases rather than doing hard-
> > coded changes.
>
> You could make the application of the patch conditional upon being the
> mips or powerpc architectures.

I think that will be more hassle than disabling it for all architectures.

>
> That does have advantages and disadvantages in that it is easy to miss
> when upgrading the glibc recipe though.
>
> Cheers,
>
> Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197873): 
https://lists.openembedded.org/g/openembedded-core/message/197873
Mute This Topic: https://lists.openembedded.org/mt/105259855/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Status 2 April 2024 (WW14)

2024-04-02 Thread Stephen Jolley
Current Dev Position: YP 5.0 M4 - Final Release

Next Deadline: 1st April 2024 YP 5.0 M4 build

Next Team Meetings:

   -

   Bug Triage meeting Thursday April 4th at 7:30 am PST (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday April 2nd at 8 am PST (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 4.0.17 has been released.
   -

   YP 4.3.4 is in QA and is the final planned nanbield release.
   -

   YP 5.0 rc1 is now due to build when ready.
   -

   Steve is taking patches for Dunfell until around April 8 in preparation
   for an April 15 build. This will be the last release of dunfell.
   -

   5.0 build status:
   -

  The opkg lock issue has been worked around for now in the
  run-postinsts script
  -

  An intermittent oe-selftest failure (sstatetests hang) was tracked
  down to a race in tinfoil event handling.
  -

  The public hash equivalence server changes aren’t ready yet
  unfortunately
  -

  There are issues with the size of the buildhistory repository which
  is being split up, this needs to happen before we can build the release.
  -

  A key worry now is the documentation for the release, especially
  given it is an LTS. There are emails on the docs list about this, help is
  much appreciated. This will now be the main delay on the release
timeframe.
  -

   A new yocto-status 
   mailing list has been created where we plan to send just the project weekly
   status reports and any other suitable updates on the project. This should
   help those who found the traffic of the other mailing lists too much.
   -

   A yocto-patches 
   mailing list has been setup and patches that used to go to the yocto@
   list will be migrating over to this new list, making yocto@ a bit more
   friendly for questions and discussions.
   -

   Some other obsolete mailing lists were removed or made read-only to try
   and make it easier for people to find the right place to see/send things.
   -

   Debian 12 and Fedora 40 containers have been added to crops (Thanks Rob
   Wolley)
   -

   All the crops yocto-base containers now include python3-virtualenv
   -

   The “Binary Distro” work is now well underway and there are PR Server
   passthrough patches ready for review. The wiki page
   

   has had a number of policy/process proposals documented, at least as a
   first pass. Help is welcome to help improve these, or highlight where
   further documentation is needed.
   -

   One year after the original linux.com article, an update was published:
   
https://www.yoctoproject.org/blog/2024/03/28/maintainer-confidential-challenges-and-opportunities-one-year-on/
   -

   There was a significant security issue with xz release tarballs. We
   never merged the affected version and it was never in any of our main
   branches but we did test it on the autobuilder and saw build failures. We
   continue to watch for information on any potential implications of that. We
   have removed the compromised tarballs from our mirrors.
   -

   We continue to watch the NIST NVD (CVE database) situation, the recent
   update didn’t clarify much. Unfortunately there doesn’t appear to be a
   clear path forward as yet.


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 5.0. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium+_5.0_Unassigned_Enhancements/Bugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   

Re: [OE-core] [PATCH] glibc: Fix stale qemu processes left after glibc oe-selftest

2024-04-02 Thread Richard Purdie
On Tue, 2024-04-02 at 12:45 +0530, Shinde, Yash via
lists.openembedded.org wrote:
>  On 02-04-2024 01:28, Khem Raj wrote:
>  it would be better to disable them just for architectures where it
> > fails since it seems to be a workaround, it would be good to keep
> > it
> > as small as possible
> > 
>  Initially, we implemented the changes to handle only for
> architectures where it fails and reviewed it with Richard in a
> meeting,
>  but it was decided to skip the test cases rather than doing hard-
> coded changes.

You could make the application of the patch conditional upon being the
mips or powerpc architectures.

That does have advantages and disadvantages in that it is easy to miss
when upgrading the glibc recipe though.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197871): 
https://lists.openembedded.org/g/openembedded-core/message/197871
Mute This Topic: https://lists.openembedded.org/mt/105259855/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH] u-boot: Upgrade to 2024.04

2024-04-02 Thread Fabio Estevam
From: Fabio Estevam 

Upgrade to U-Boot 2024.04.

Signed-off-by: Fabio Estevam 
---
 meta/recipes-bsp/u-boot/u-boot-common.inc   | 2 +-
 .../u-boot/{u-boot-tools_2024.01.bb => u-boot-tools_2024.04.bb} | 0
 .../recipes-bsp/u-boot/{u-boot_2024.01.bb => u-boot_2024.04.bb} | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-bsp/u-boot/{u-boot-tools_2024.01.bb => 
u-boot-tools_2024.04.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2024.01.bb => u-boot_2024.04.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index 1f17bd7d0af2..f88ee44c1ad4 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -12,7 +12,7 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e"
+SRCREV = "25049ad560826f7dc1c4740883b0016014a59789"
 
 SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2024.04.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2024.04.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2024.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2024.04.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2024.01.bb
rename to meta/recipes-bsp/u-boot/u-boot_2024.04.bb
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197870): 
https://lists.openembedded.org/g/openembedded-core/message/197870
Mute This Topic: https://lists.openembedded.org/mt/105286006/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core][dunfell][PATCH v2] Backport missing licenses

2024-04-02 Thread Quentin Schulz via lists.openembedded.org

Hi all,

I would recommend to identify the patches to backport from the master 
branch and backport those instead of sending one huge patch, lowering 
the risk of forgetting some changes, forgetting to fix some git 
conflicts, etc...


Also considering that Dunfell is soon (this month) EoL, not sure it's 
worth the contributor's effort? But that's up to Colin to decide :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197869): 
https://lists.openembedded.org/g/openembedded-core/message/197869
Mute This Topic: https://lists.openembedded.org/mt/105265076/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [Openembedded-architecture] New mailing list for layer patches

2024-04-02 Thread Paul Barker
On 28/03/2024 14:36, Ross Burton wrote:
> Hi,
> 
> At the moment if a layer doesn’t have enough volume to justify a dedicated 
> mailing list for patches (see, for example, meta-...@lists.yoctoproject.org 
> ) then the convention is that the 
> patches can be sent to yo...@lists.yoctoproject.org 
> .
> 
> However, that’s also the list that we encourage users of Yocto to use for 
> help, so the list has a mix of patches for various layers and people asking 
> for help, which isn’t ideal: users who want help don’t want to be flooded 
> with patches for layers they’re not using, layer maintainers may not want to 
> see the requests for help, and people who want the status reports have to 
> receive patches and support.
> 
> The Yocto TSC has been discussing this, and as a solution to this we’ve just 
> created a new mailing list: yocto-patc...@lists.yoctoproject.org 
> .  This list is specifically for 
> Yocto-related projects which don’t have their own mailing list or other patch 
> submission process.   We ask that all layers currently using yocto@ for 
> patches move to yocto-patches@, so that yocto@ can be used purely for 
> discussion and other non-patch related subjects.

I think this is a great change, along with the new yocto-status@ list it will 
make things easier to follow :)

Do you know if yocto-patches@ will be available via lore.kernel.org?

Thanks,

-- 
Paul Barker


OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197868): 
https://lists.openembedded.org/g/openembedded-core/message/197868
Mute This Topic: https://lists.openembedded.org/mt/105284126/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] glibc: Fix stale qemu processes left after glibc oe-selftest

2024-04-02 Thread Shinde, Yash via lists.openembedded.org


On 02-04-2024 01:28, Khem Raj wrote:

it would be better to disable them just for architectures where it
fails since it seems to be a workaround, it would be good to keep it
as small as possible

Initially, we implemented the changes to handle only for architectures 
where it fails and reviewed it with Richard in a meeting,
but it was decided to skip the test cases rather than doing hard-coded 
changes.


Regards,
Yash

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197867): 
https://lists.openembedded.org/g/openembedded-core/message/197867
Mute This Topic: https://lists.openembedded.org/mt/105259855/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-