[OE-core] [PATCH] mesa: only apply patch to fix ALWAYS_INLINE for native

[kai]

From: Kai Kang 

0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch is not
required by target mesa any more. But it still fails to compile
mesa-native with DEBUG_BUILD enabled on Ubuntu 18.04 with gcc 7.5.0
without this patch:

| ../mesa-22.1.6/src/compiler/nir/nir_inline_helpers.h: In function 
‘nir_opt_move_block’:
| ../mesa-22.1.6/src/compiler/nir/nir_opt_move.c:55:1: error: inlining failed 
in call to
always_inline ‘src_is_ssa’: indirect function call with a yet undetermined 
callee
|  src_is_ssa(nir_src *src, void *state)
|  ^~

So only apply it for mesa-native.

Signed-off-by: Kai Kang 
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index ea7ed4fd27..c306c6b726 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -22,8 +22,8 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-util-format-Check-for-NEON-before-using-it.patch \

file://0001-Revert-egl-wayland-deprecate-drm_handle_format-and-d.patch \

file://0001-swrast_kms-use-swkmsDRI2Extension-instead-of-driDRI2.patch \
-   file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch 
\
"
+SRC_URI:append:class-native = " 
file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
 
 SRC_URI[sha256sum] = 
"22ced061eb9adab8ea35368246c1995c09723f3f71653cd5050c5cec376e671a"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170930): 
https://lists.openembedded.org/g/openembedded-core/message/170930
Mute This Topic: https://lists.openembedded.org/mt/93820842/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][PATCH 2/2] tune-neoversen2: support tune-neoversen2 base on armv9a

[Ruiqiang Hao]

From: Ruiqiang Hao 

We supported neoversen2 base on armv8.5a in the past, add tune include
for armv9a and support neoversen2 base on armv9a.

Signed-off-by: Ruiqiang Hao 
---
 meta/conf/machine/include/arm/arch-armv9a.inc | 28 +++
 .../include/arm/armv9a/tune-neoversen2.inc| 10 +++
 2 files changed, 32 insertions(+), 6 deletions(-)
 create mode 100644 meta/conf/machine/include/arm/arch-armv9a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv9a.inc 
b/meta/conf/machine/include/arm/arch-armv9a.inc
new file mode 100644
index 00..c38d6cfdf6
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv9a.inc
@@ -0,0 +1,28 @@
+DEFAULTTUNE ?= "armv9a-crc"
+
+TUNEVALID[armv9a] = "Enable instructions for ARMv9-a"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv9a', ' 
-march=armv9-a', '', d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv9a', 
'armv9a:', '', d)}"
+
+require conf/machine/include/arm/arch-arm64.inc
+require conf/machine/include/arm/feature-arm-crc.inc
+require conf/machine/include/arm/feature-arm-crypto.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv9a armv9a-crc armv9a-crc-crypto armv9a-crypto"
+ARMPKGARCH:tune-armv9a?= "armv9a"
+ARMPKGARCH:tune-armv9a-crc?= "armv9a"
+ARMPKGARCH:tune-armv9a-crypto ?= "armv9a"
+ARMPKGARCH:tune-armv9a-crc-crypto ?= "armv9a"
+TUNE_FEATURES:tune-armv9a  = "aarch64 armv9a"
+TUNE_FEATURES:tune-armv9a-crc  = "${TUNE_FEATURES:tune-armv9a} crc"
+TUNE_FEATURES:tune-armv9a-crypto   = "${TUNE_FEATURES:tune-armv9a} 
crypto"
+TUNE_FEATURES:tune-armv9a-crc-crypto   = "${TUNE_FEATURES:tune-armv9a-crc} 
crypto"
+PACKAGE_EXTRA_ARCHS:tune-armv9a= "aarch64 armv9a"
+PACKAGE_EXTRA_ARCHS:tune-armv9a-crc= 
"${PACKAGE_EXTRA_ARCHS:tune-armv9a} armv9a-crc"
+PACKAGE_EXTRA_ARCHS:tune-armv9a-crypto = 
"${PACKAGE_EXTRA_ARCHS:tune-armv9a} armv9a-crypto"
+PACKAGE_EXTRA_ARCHS:tune-armv9a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS:tune-armv9a-crc} armv9a-crypto armv9a-crc-crypto"
+BASE_LIB:tune-armv9a   = "lib64"
+BASE_LIB:tune-armv9a-crc   = "lib64"
+BASE_LIB:tune-armv9a-crypto= "lib64"
+BASE_LIB:tune-armv9a-crc-crypto= "lib64"
diff --git a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc 
b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
index 36355f7bed..d26ab25e48 100644
--- a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
+++ b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
@@ -6,17 +6,15 @@ DEFAULTTUNE ?= "neoversen2"
 TUNEVALID[neoversen2] = "Enable Neoverse-N2 specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neoversen2', ' 
-mcpu=neoverse-n2', '', d)}"
 
-# Even though the Neoverse N2 core implemnts the Arm v9.0-A architecture,
-# but the support of it in GCC is based on the Arm v8.5-A architecture.
-require conf/machine/include/arm/arch-armv8-5a.inc
+require conf/machine/include/arm/arch-armv9a.inc
 
 # Little Endian base configs
 AVAILTUNES += "neoversen2 
neoversen2-crypto"
 ARMPKGARCH:tune-neoversen2  = "neoversen2"
 ARMPKGARCH:tune-neoversen2-crypto   = "neoversen2-crypto"
-TUNE_FEATURES:tune-neoversen2   = 
"${TUNE_FEATURES:tune-armv8-5a} neoversen2"
+TUNE_FEATURES:tune-neoversen2   = 
"${TUNE_FEATURES:tune-armv9a} neoversen2"
 TUNE_FEATURES:tune-neoversen2-crypto= 
"${TUNE_FEATURES:tune-neoversen2} crypto"
-PACKAGE_EXTRA_ARCHS:tune-neoversen2 = 
"${PACKAGE_EXTRA_ARCHS:tune-armv8-5a} neoversen2"
-PACKAGE_EXTRA_ARCHS:tune-neoversen2-crypto  = 
"${PACKAGE_EXTRA_ARCHS:tune-armv8-5a-crypto} neoversen2 neoversen2-crypto"
+PACKAGE_EXTRA_ARCHS:tune-neoversen2 = 
"${PACKAGE_EXTRA_ARCHS:tune-armv9a} neoversen2"
+PACKAGE_EXTRA_ARCHS:tune-neoversen2-crypto  = 
"${PACKAGE_EXTRA_ARCHS:tune-armv9a-crypto} neoversen2 neoversen2-crypto"
 BASE_LIB:tune-neoversen2= "lib64"
 BASE_LIB:tune-neoversen2-crypto = "lib64"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170929): 
https://lists.openembedded.org/g/openembedded-core/message/170929
Mute This Topic: https://lists.openembedded.org/mt/93819775/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][PATCH 1/2] gcc: add arm-v9 support

[Ruiqiang Hao]

From: Ruiqiang Hao 

Backport some patches from GCC 12 to support arm-v9.

Signed-off-by: Ruiqiang Hao 
---
 meta/recipes-devtools/gcc/gcc-11.3.inc|   5 +
 ...rch64-Update-Neoverse-N2-core-defini.patch |  42 +++
 .../0002-aarch64-add-armv9-a-to-march.patch   |  89 ++
 ...le-FP16-feature-by-default-for-Armv9.patch |  38 +++
 ...rm-add-armv9-a-architecture-to-march.patch | 294 ++
 5 files changed, 468 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0001-aarch64-Update-Neoverse-N2-core-defini.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0002-aarch64-add-armv9-a-to-march.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0003-aarch64-Enable-FP16-feature-by-default-for-Armv9.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc 
b/meta/recipes-devtools/gcc/gcc-11.3.inc
index acbb43a25f..0f1799d383 100644
--- a/meta/recipes-devtools/gcc/gcc-11.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.3.inc
@@ -65,7 +65,12 @@ SRC_URI = "\
file://0003-CVE-2021-42574.patch \
file://0004-CVE-2021-42574.patch \
file://0001-CVE-2021-46195.patch \
+  file://0001-aarch64-Update-Neoverse-N2-core-defini.patch \
+  file://0002-aarch64-add-armv9-a-to-march.patch \
+  file://0003-aarch64-Enable-FP16-feature-by-default-for-Armv9.patch \
+  file://0004-arm-add-armv9-a-architecture-to-march.patch \
 "
+
 SRC_URI[sha256sum] = 
"b47cf2818691f5b1e21df2bb38c795fac2cfbd640ede2d0a5e1c89e338a3ac39"
 
 S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
diff --git 
a/meta/recipes-devtools/gcc/gcc/0001-aarch64-Update-Neoverse-N2-core-defini.patch
 
b/meta/recipes-devtools/gcc/gcc/0001-aarch64-Update-Neoverse-N2-core-defini.patch
new file mode 100644
index 00..8429242348
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc/0001-aarch64-Update-Neoverse-N2-core-defini.patch
@@ -0,0 +1,42 @@
+From 9f37d31324f89d0b7b2abac988a976d121ae29c6 Mon Sep 17 00:00:00 2001
+From: Andre Vieira 
+Date: Thu, 8 Sep 2022 06:02:18 +
+Subject: [PATCH 1/4] aarch64: Update Neoverse N2 core definition
+
+commit 9f37d31324f89d0b7b2abac988a976d121ae29c6 from upstream.
+
+gcc/ChangeLog:
+
+* config/aarch64/aarch64-cores.def: Update Neoverse N2 core entry.
+
+Upstream-Status: Backport
+Signed-off-by: Ruiqiang Hao 
+---
+ gcc/config/aarch64/aarch64-cores.def | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
+index 4643e0e27..3478e567a 100644
+--- a/gcc/config/aarch64/aarch64-cores.def
 b/gcc/config/aarch64/aarch64-cores.def
+@@ -145,9 +145,6 @@ AARCH64_CORE("neoverse-512tvb", neoverse512tvb, cortexa57, 
8_4A,  AARCH64_FL_FOR
+ /* Qualcomm ('Q') cores. */
+ AARCH64_CORE("saphira", saphira,saphira,8_4A,  
AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC, saphira,   0x51, 
0xC01, -1)
+ 
+-/* Armv8.5-A Architecture Processors.  */
+-AARCH64_CORE("neoverse-n2", neoversen2, cortexa57, 8_5A, 
AARCH64_FL_FOR_ARCH8_5 | AARCH64_FL_I8MM | AARCH64_FL_BF16 | AARCH64_FL_F16 | 
AARCH64_FL_SVE | AARCH64_FL_SVE2 | AARCH64_FL_SVE2_BITPERM | AARCH64_FL_RNG | 
AARCH64_FL_MEMTAG, neoversen2, 0x41, 0xd49, -1)
+-
+ /* ARMv8-A big.LITTLE implementations.  */
+ 
+ AARCH64_CORE("cortex-a57.cortex-a53",  cortexa57cortexa53, cortexa53, 8A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57, 0x41, AARCH64_BIG_LITTLE 
(0xd07, 0xd03), -1)
+@@ -163,4 +160,7 @@ AARCH64_CORE("cortex-a76.cortex-a55",  cortexa76cortexa55, 
cortexa53, 8_2A,  AAR
+ /* Armv8-R Architecture Processors.  */
+ AARCH64_CORE("cortex-r82", cortexr82, cortexa53, 8R, AARCH64_FL_FOR_ARCH8_R, 
cortexa53, 0x41, 0xd15, -1)
+ 
++/* Armv9-A Architecture Processors. */
++AARCH64_CORE("neoverse-n2", neoversen2, cortexa57, 9A, AARCH64_FL_FOR_ARCH9 | 
AARCH64_FL_I8MM | AARCH64_FL_BF16 | AARCH64_FL_SVE2_BITPERM | AARCH64_FL_RNG | 
AARCH64_FL_MEMTAG | AARCH64_FL_PROFILE, neoversen2, 0x41, 0xd49, -1)
++
+ #undef AARCH64_CORE
+-- 
+2.32.0
+
diff --git 
a/meta/recipes-devtools/gcc/gcc/0002-aarch64-add-armv9-a-to-march.patch 
b/meta/recipes-devtools/gcc/gcc/0002-aarch64-add-armv9-a-to-march.patch
new file mode 100644
index 00..2b1c17f53e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc/0002-aarch64-add-armv9-a-to-march.patch
@@ -0,0 +1,89 @@
+From d3cf45d15b2fabc767b2d10a0c6bb9fb845e4f99 Mon Sep 17 00:00:00 2001
+From: Przemyslaw Wirkus 
+Date: Fri, 1 Oct 2021 10:06:45 +0100
+Subject: [PATCH 2/4] aarch64: add armv9-a to -march
+
+commit f0688d42c9b74a6999548ff2e79ae440b049b87f from upstream
+
+gcc/ChangeLog:
+
+   * config/aarch64/aarch64-arches.def (AARCH64_ARCH): Added
+   armv9-a.
+   * config/aarch64/aarch64.h (AARCH64_FL_V9): New.
+   (AARCH64_FL_FOR_ARCH9): New flags for Armv9-A.
+   (AARCH64_ISA_V9): New ISA flag.
+   * doc/invoke.texi: 

Re: [OE-core] [PATCH][dunfell 2/2] qemu: fix and ignore several CVEs

[Steve Sakoman]

On Sun, Sep 18, 2022 at 2:44 PM Mittal, Anuj  wrote:
>
>
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Steve Sakoman
> > Sent: Thursday, September 15, 2022 10:14 PM
> > To: Lee, Chee Yang 
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH][dunfell 2/2] qemu: fix and ignore several 
> > CVEs
> >
> > On Tue, Sep 13, 2022 at 8:04 PM Lee Chee Yang  
> > wrote:
> > >
> > > From: Chee Yang Lee 
> > >
> > > backport fixes:
> > > CVE-2020-13754, backport patches as debian security tracker notes
> > >   https://security-tracker.debian.org/tracker/CVE-2020-13754
> > >
> > > CVE-2021-3713
> > > CVE-2021-3748
> > > CVE-2021-3930
> > > CVE-2021-4206
> > > CVE-2021-4207
> > > CVE-2022-0216, does not include qtest in patches, the qtest code were not 
> > > available
> > in v4.2.
> > >
> > > Ignore:
> > > CVE-2020-27661, issue introduced in v5.1.0-rc0
> > > https://security-tracker.debian.org/tracker/CVE-2020-27661
> >
> > While this patch applies and builds without error, it results in quite a 
> > few runtime
> > errors during
> > oe-selftest:
> >
> > https://errors.yoctoproject.org/Errors/Details/671970/
> >
> > Not sure which of the CVE fixes cause this :-(
>
> It might be because of:
>
> https://lists.openembedded.org/g/openembedded-core/message/156694

Yes, on further investigation there are no issues with this patch.
The issues were with a couple of missing PACKAGECONFIGS in the qemu
recipe. After adding those all is well again.

Thanks for the hint Anuj!

Steve

> > > Signed-off-by: Chee Yang Lee 
> > > ---
> > >  meta/recipes-devtools/qemu/qemu.inc   |  14 ++
> > >  .../qemu/qemu/CVE-2020-13754-1.patch  |  91 +
> > >  .../qemu/qemu/CVE-2020-13754-2.patch  |  69 ++
> > >  .../qemu/qemu/CVE-2020-13754-3.patch  |  65 +
> > >  .../qemu/qemu/CVE-2020-13754-4.patch  |  39 ++
> > >  .../qemu/qemu/CVE-2021-3713.patch |  67 ++
> > >  .../qemu/qemu/CVE-2021-3748.patch | 124 ++
> > >  .../qemu/qemu/CVE-2021-3930.patch |  53 
> > >  .../qemu/qemu/CVE-2021-4206.patch |  89 +
> > >  .../qemu/qemu/CVE-2021-4207.patch |  43 ++
> > >  .../qemu/qemu/CVE-2022-0216-1.patch   |  42 ++
> > >  .../qemu/qemu/CVE-2022-0216-2.patch   |  52 
> > >  12 files changed, 748 insertions(+)
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2020-13754-2.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2020-13754-3.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2020-13754-4.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2021-3713.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2021-3930.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2021-4206.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2021-4207.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2022-0216-1.patch
> > >  create mode 100644
> > > meta/recipes-devtools/qemu/qemu/CVE-2022-0216-2.patch
> > >
> > > diff --git a/meta/recipes-devtools/qemu/qemu.inc
> > > b/meta/recipes-devtools/qemu/qemu.inc
> > > index a773068499..c1db723e90 100644
> > > --- a/meta/recipes-devtools/qemu/qemu.inc
> > > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > > @@ -100,6 +100,17 @@ SRC_URI = "https://download.qemu.org/${BPN}-
> > ${PV}.tar.xz \
> > > file://CVE-2020-13791.patch \
> > > file://CVE-2022-35414.patch \
> > > file://CVE-2020-27821.patch \
> > > +   file://CVE-2020-13754-1.patch \
> > > +   file://CVE-2020-13754-2.patch \
> > > +   file://CVE-2020-13754-3.patch \
> > > +   file://CVE-2020-13754-4.patch \
> > > +   file://CVE-2021-3713.patch \
> > > +   file://CVE-2021-3748.patch \
> > > +   file://CVE-2021-3930.patch \
> > > +   file://CVE-2021-4206.patch \
> > > +   file://CVE-2021-4207.patch \
> > > +   file://CVE-2022-0216-1.patch \
> > > +   file://CVE-2022-0216-2.patch \
> > > "
> > >  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
> > >
> > > @@ -117,6 +128,9 @@ CVE_CHECK_WHITELIST += "CVE-2007-0998"
> > >  # https://bugzilla.redhat.com/show_bug.cgi?id=1609015#c11
> > >  CVE_CHECK_WHITELIST += "CVE-2018-18438"
> > >
> > > +# the issue introduced in v5.1.0-rc0
> > > +CVE_CHECK_WHITELIST += "CVE-2020-27661"
> > > +
> > >  COMPATIBLE_HOST_mipsarchn32 = "null"
> > >  COMPATIBLE_HOST_mipsarchn64 = "null"
> > >
> > > diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch

[OE-core][dunfell 6/6] qemu: Add PACKAGECONFIG for brlapi

[Steve Sakoman]

From: Richard Purdie 

Signed-off-by: Richard Purdie 
(cherry picked from commit 482471a617e5f682416b7ec1a920dfaeac65f1a3)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index b432b01224..368be9979a 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -273,6 +273,7 @@ PACKAGECONFIG[seccomp] = 
"--enable-seccomp,--disable-seccomp,libseccomp"
 PACKAGECONFIG[capstone] = "--enable-capstone,--disable-capstone"
 # libnfs is currently provided by meta-kodi
 PACKAGECONFIG[libnfs] = "--enable-libnfs,--disable-libnfs,libnfs"
+PACKAGECONFIG[brlapi] = "--enable-brlapi,--disable-brlapi"
 
 INSANE_SKIP_${PN} = "arch"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170926): 
https://lists.openembedded.org/g/openembedded-core/message/170926
Mute This Topic: https://lists.openembedded.org/mt/93819357/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/6] qemu: fix and ignore several CVEs

[Steve Sakoman]

From: Chee Yang Lee 

backport fixes:
CVE-2020-13754, backport patches as debian security tracker notes
  https://security-tracker.debian.org/tracker/CVE-2020-13754

CVE-2021-3713
CVE-2021-3748
CVE-2021-3930
CVE-2021-4206
CVE-2021-4207
CVE-2022-0216, does not include qtest in patches, the qtest code were not 
available in v4.2.

Ignore:
CVE-2020-27661, issue introduced in v5.1.0-rc0
https://security-tracker.debian.org/tracker/CVE-2020-27661

Signed-off-by: Chee Yang Lee 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc   |  14 ++
 .../qemu/qemu/CVE-2020-13754-1.patch  |  91 +
 .../qemu/qemu/CVE-2020-13754-2.patch  |  69 ++
 .../qemu/qemu/CVE-2020-13754-3.patch  |  65 +
 .../qemu/qemu/CVE-2020-13754-4.patch  |  39 ++
 .../qemu/qemu/CVE-2021-3713.patch |  67 ++
 .../qemu/qemu/CVE-2021-3748.patch | 124 ++
 .../qemu/qemu/CVE-2021-3930.patch |  53 
 .../qemu/qemu/CVE-2021-4206.patch |  89 +
 .../qemu/qemu/CVE-2021-4207.patch |  43 ++
 .../qemu/qemu/CVE-2022-0216-1.patch   |  42 ++
 .../qemu/qemu/CVE-2022-0216-2.patch   |  52 
 12 files changed, 748 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-3.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-4.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3713.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3930.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-4206.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-4207.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-0216-1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-0216-2.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index a773068499..c1db723e90 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -100,6 +100,17 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2020-13791.patch \
file://CVE-2022-35414.patch \
file://CVE-2020-27821.patch \
+   file://CVE-2020-13754-1.patch \
+   file://CVE-2020-13754-2.patch \
+   file://CVE-2020-13754-3.patch \
+   file://CVE-2020-13754-4.patch \
+   file://CVE-2021-3713.patch \
+   file://CVE-2021-3748.patch \
+   file://CVE-2021-3930.patch \
+   file://CVE-2021-4206.patch \
+   file://CVE-2021-4207.patch \
+   file://CVE-2022-0216-1.patch \
+   file://CVE-2022-0216-2.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
@@ -117,6 +128,9 @@ CVE_CHECK_WHITELIST += "CVE-2007-0998"
 # https://bugzilla.redhat.com/show_bug.cgi?id=1609015#c11
 CVE_CHECK_WHITELIST += "CVE-2018-18438"
 
+# the issue introduced in v5.1.0-rc0
+CVE_CHECK_WHITELIST += "CVE-2020-27661"
+
 COMPATIBLE_HOST_mipsarchn32 = "null"
 COMPATIBLE_HOST_mipsarchn64 = "null"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch
new file mode 100644
index 00..fdfff9d81d
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch
@@ -0,0 +1,91 @@
+From 5d971f9e672507210e77d020d89e0e89165c8fc9 Mon Sep 17 00:00:00 2001
+From: "Michael S. Tsirkin" 
+Date: Wed, 10 Jun 2020 09:47:49 -0400
+Subject: [PATCH] memory: Revert "memory: accept mismatching sizes in
+ memory_region_access_valid"
+
+Memory API documentation documents valid .min_access_size and .max_access_size
+fields and explains that any access outside these boundaries is blocked.
+
+This is what devices seem to assume.
+
+However this is not what the implementation does: it simply
+ignores the boundaries unless there's an "accepts" callback.
+
+Naturally, this breaks a bunch of devices.
+
+Revert to the documented behaviour.
+
+Devices that want to allow any access can just drop the valid field,
+or add the impl field to have accesses converted to appropriate
+length.
+
+Cc: qemu-sta...@nongnu.org
+Reviewed-by: Richard Henderson 
+Fixes: CVE-2020-13754
+Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1842363
+Fixes: a014ed07bd5a ("memory: accept mismatching sizes in 
memory_region_access_valid")
+Signed-off-by: Michael S. Tsirkin 
+Message-Id: <20200610134731.1514409-1-...@redhat.com>
+Signed-off-by: Paolo Bonzini 
+
+https://git.qemu.org/?p=qemu.git;a=patch;h=5d971f9e672507210e77d020d89e0e89165c8fc9
+CVE: CVE-2020-13754
+Upstream-Status: Backport
+Signed-off-by: Chee Yang Lee 
+---
+ memory.c | 29 

[OE-core][dunfell 5/6] qemu: Define libnfs PACKAGECONFIG

[Steve Sakoman]

From: Andrei Gherzan 

The upstream qemu recipe uses host's pkg-config files as a solution to
detecting host's SDL. This has a side effect of using other host
libraries that are later queried by the configure script. This can get
into a situation when the host provides libnfs (for example) and because
later this dependency is not in place anymore, qemu will fail at
runtime.

This change adds a PACKAGECONFIG definition for libnfs that is disabled
by default, in turn disabling the pkgconfig autodetection in configure.

Signed-off-by: Andrei Gherzan 
Signed-off-by: Richard Purdie 
(cherry picked from commit 42b364a25fdbc987c85dd46b8427045033924d99)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index c1db723e90..b432b01224 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -271,6 +271,8 @@ PACKAGECONFIG[libudev] = 
"--enable-libudev,--disable-libudev,eudev"
 PACKAGECONFIG[libxml2] = "--enable-libxml2,--disable-libxml2,libxml2"
 PACKAGECONFIG[seccomp] = "--enable-seccomp,--disable-seccomp,libseccomp"
 PACKAGECONFIG[capstone] = "--enable-capstone,--disable-capstone"
+# libnfs is currently provided by meta-kodi
+PACKAGECONFIG[libnfs] = "--enable-libnfs,--disable-libnfs,libnfs"
 
 INSANE_SKIP_${PN} = "arch"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170925): 
https://lists.openembedded.org/g/openembedded-core/message/170925
Mute This Topic: https://lists.openembedded.org/mt/93819356/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/6] connman: CVE-2022-32293 man-in-the-middle attack against a WISPR HTTP

[Steve Sakoman]

From: Hitendra Prajapati 

Source: https://git.kernel.org/pub/scm/network/connman/connman.git/
MR: 120508
Type: Security Fix
Disposition: Backport from 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=72343929836de80727a27d6744c869dff045757c
 && 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/src/wispr.c?id=416bfaff92c553c672e5bfc2d4f648d29e8a
ChangeID: 1583badc6de6bb8a7f63c06749b90b97caab5cdf
Description:
 CVE-2022-32293 connman: man-in-the-middle attack against a WISPR HTTP.

Signed-off-by: Hitendra Prajapati 
Signed-off-by: Steve Sakoman 
---
 .../connman/connman/CVE-2022-32293.patch  | 266 ++
 .../connman/connman_1.37.bb   |   1 +
 2 files changed, 267 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch

diff --git a/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch 
b/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch
new file mode 100644
index 00..83a013981c
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch
@@ -0,0 +1,266 @@
+From 358a44b1442fae0f82846e10da0708b5c4e1ce27 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Tue, 20 Sep 2022 17:58:19 +0530
+Subject: [PATCH] CVE-2022-32293
+
+CVE: CVE-2022-32293
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=72343929836de80727a27d6744c869dff045757c
 && 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/src/wispr.c?id=416bfaff92c553c672e5bfc2d4f648d29e8a]
+Signed-off-by: Hitendra Prajapati 
+---
+ src/wispr.c | 83 -
+ 1 file changed, 63 insertions(+), 20 deletions(-)
+
+diff --git a/src/wispr.c b/src/wispr.c
+index 473c0e0..97e0242 100644
+--- a/src/wispr.c
 b/src/wispr.c
+@@ -59,6 +59,7 @@ struct wispr_route {
+ };
+ 
+ struct connman_wispr_portal_context {
++  int refcount;
+   struct connman_service *service;
+   enum connman_ipconfig_type type;
+   struct connman_wispr_portal *wispr_portal;
+@@ -96,10 +97,13 @@ static bool wispr_portal_web_result(GWebResult *result, 
gpointer user_data);
+ 
+ static GHashTable *wispr_portal_list = NULL;
+ 
++#define wispr_portal_context_ref(wp_context) \
++  wispr_portal_context_ref_debug(wp_context, __FILE__, __LINE__, __func__)
++#define wispr_portal_context_unref(wp_context) \
++  wispr_portal_context_unref_debug(wp_context, __FILE__, __LINE__, 
__func__)
++
+ static void connman_wispr_message_init(struct connman_wispr_message *msg)
+ {
+-  DBG("");
+-
+   msg->has_error = false;
+   msg->current_element = NULL;
+ 
+@@ -159,11 +163,6 @@ static void free_wispr_routes(struct 
connman_wispr_portal_context *wp_context)
+ static void free_connman_wispr_portal_context(
+   struct connman_wispr_portal_context *wp_context)
+ {
+-  DBG("context %p", wp_context);
+-
+-  if (!wp_context)
+-  return;
+-
+   if (wp_context->wispr_portal) {
+   if (wp_context->wispr_portal->ipv4_context == wp_context)
+   wp_context->wispr_portal->ipv4_context = NULL;
+@@ -200,9 +199,38 @@ static void free_connman_wispr_portal_context(
+   g_free(wp_context);
+ }
+ 
++static struct connman_wispr_portal_context *
++wispr_portal_context_ref_debug(struct connman_wispr_portal_context 
*wp_context,
++  const char *file, int line, const char *caller)
++{
++  DBG("%p ref %d by %s:%d:%s()", wp_context,
++  wp_context->refcount + 1, file, line, caller);
++
++  __sync_fetch_and_add(_context->refcount, 1);
++
++  return wp_context;
++}
++
++static void wispr_portal_context_unref_debug(
++  struct connman_wispr_portal_context *wp_context,
++  const char *file, int line, const char *caller)
++{
++  if (!wp_context)
++  return;
++
++  DBG("%p ref %d by %s:%d:%s()", wp_context,
++  wp_context->refcount - 1, file, line, caller);
++
++  if (__sync_fetch_and_sub(_context->refcount, 1) != 1)
++  return;
++
++  free_connman_wispr_portal_context(wp_context);
++}
++
+ static struct connman_wispr_portal_context *create_wispr_portal_context(void)
+ {
+-  return g_try_new0(struct connman_wispr_portal_context, 1);
++  return wispr_portal_context_ref(
++  g_new0(struct connman_wispr_portal_context, 1));
+ }
+ 
+ static void free_connman_wispr_portal(gpointer data)
+@@ -214,8 +242,8 @@ static void free_connman_wispr_portal(gpointer data)
+   if (!wispr_portal)
+   return;
+ 
+-  free_connman_wispr_portal_context(wispr_portal->ipv4_context);
+-  free_connman_wispr_portal_context(wispr_portal->ipv6_context);
++  wispr_portal_context_unref(wispr_portal->ipv4_context);
++  wispr_portal_context_unref(wispr_portal->ipv6_context);
+ 
+   g_free(wispr_portal);
+ }
+@@ 

[OE-core][dunfell 2/6] sqlite3: Fix CVE-2020-35527

[Steve Sakoman]

From: Virendra Thakur 

Add patch file to fix CVE-2020-35527

Reference:
http://security.debian.org/debian-security/pool/updates/main/s/sqlite3/sqlite3_3.27.2-3+deb10u2.debian.tar.xz

Signed-off-by: Virendra Thakur 
Signed-off-by: Steve Sakoman 
---
 .../sqlite/files/CVE-2020-35527.patch | 22 +++
 meta/recipes-support/sqlite/sqlite3_3.31.1.bb |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-35527.patch

diff --git a/meta/recipes-support/sqlite/files/CVE-2020-35527.patch 
b/meta/recipes-support/sqlite/files/CVE-2020-35527.patch
new file mode 100644
index 00..d1dae389b0
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2020-35527.patch
@@ -0,0 +1,22 @@
+From: dan 
+Date: Mon, 26 Oct 2020 13:24:36 +
+Subject: [PATCH] Fix a problem with ALTER TABLE for views that have a nested
+ FROM clause. Ticket [f50af3e8a565776b].
+
+Upstream-Status: Backport 
[http://security.debian.org/debian-security/pool/updates/main/s/sqlite3/sqlite3_3.27.2-3+deb10u2.debian.tar.xz]
+CVE: CVE-2020-35527
+Signed-off-by: Virendra Thakur 
+---
+Index: sqlite-autoconf-3310100/sqlite3.c
+===
+--- sqlite-autoconf-3310100.orig/sqlite3.c
 sqlite-autoconf-3310100/sqlite3.c
+@@ -133110,7 +133110,7 @@ static int selectExpander(Walker *pWalke
+ pNew = sqlite3ExprListAppend(pParse, pNew, pExpr);
+ sqlite3TokenInit(, zColname);
+ sqlite3ExprListSetName(pParse, pNew, , 0);
+-if( pNew && (p->selFlags & SF_NestedFrom)!=0 ){
++if( pNew && (p->selFlags & SF_NestedFrom)!=0 && !IN_RENAME_OBJECT 
){
+   struct ExprList_item *pX = >a[pNew->nExpr-1];
+   sqlite3DbFree(db, pX->zEName);
+   if( pSub ){
diff --git a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb 
b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
index 48051593e4..d9e98c9120 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
@@ -15,6 +15,7 @@ SRC_URI = 
"http://www.sqlite.org/2020/sqlite-autoconf-${SQLITE_PV}.tar.gz \
file://CVE-2020-13632.patch \
file://CVE-2022-35737.patch \
file://CVE-2020-35525.patch \
+   file://CVE-2020-35527.patch \
"
 SRC_URI[md5sum] = "2d0a553534c521504e3ac3ad3b90f125"
 SRC_URI[sha256sum] = 
"62284efebc05a76f909c580ffa5c008a7d22a1287285d68b7825a2b6b51949ae"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170922): 
https://lists.openembedded.org/g/openembedded-core/message/170922
Mute This Topic: https://lists.openembedded.org/mt/93819353/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 1/6] sqlite3: Fix CVE-2020-35525

[Steve Sakoman]

From: Virendra Thakur 

Add patch to fix CVE-2020-35525

Reference:
http://security.debian.org/debian-security/pool/updates/main/s/sqlite3/sqlite3_3.27.2-3+deb10u2.debian.tar.xz

Signed-off-by: Virendra Thakur 
Signed-off-by: Steve Sakoman 
---
 .../sqlite/files/CVE-2020-35525.patch | 21 +++
 meta/recipes-support/sqlite/sqlite3_3.31.1.bb |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-35525.patch

diff --git a/meta/recipes-support/sqlite/files/CVE-2020-35525.patch 
b/meta/recipes-support/sqlite/files/CVE-2020-35525.patch
new file mode 100644
index 00..27d81d42d9
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2020-35525.patch
@@ -0,0 +1,21 @@
+From: drh 
+Date: Thu, 20 Feb 2020 14:08:51 +
+Subject: [PATCH] Early-out on the INTERSECT query processing following an
+ error.
+
+Upstream-Status: Backport 
[http://security.debian.org/debian-security/pool/updates/main/s/sqlite3/sqlite3_3.27.2-3+deb10u2.debian.tar.xz]
+CVE: CVE-2020-35525
+Signed-off-by: Virendra Thakur 
+---
+Index: sqlite-autoconf-3310100/sqlite3.c
+===
+--- sqlite-autoconf-3310100.orig/sqlite3.c
 sqlite-autoconf-3310100/sqlite3.c
+@@ -130767,6 +130767,7 @@ static int multiSelect(
+ /* Generate code to take the intersection of the two temporary
+ ** tables.
+ */
++if( rc ) break;
+ assert( p->pEList );
+ iBreak = sqlite3VdbeMakeLabel(pParse);
+ iCont = sqlite3VdbeMakeLabel(pParse);
diff --git a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb 
b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
index 3440bf4913..48051593e4 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"http://www.sqlite.org/2020/sqlite-autoconf-${SQLITE_PV}.tar.gz \
file://CVE-2020-13631.patch \
file://CVE-2020-13632.patch \
file://CVE-2022-35737.patch \
+   file://CVE-2020-35525.patch \
"
 SRC_URI[md5sum] = "2d0a553534c521504e3ac3ad3b90f125"
 SRC_URI[sha256sum] = 
"62284efebc05a76f909c580ffa5c008a7d22a1287285d68b7825a2b6b51949ae"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170921): 
https://lists.openembedded.org/g/openembedded-core/message/170921
Mute This Topic: https://lists.openembedded.org/mt/93819352/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 0/6] Patch review

[Steve Sakoman]

Please review this set of patches for dunfell and have comments back by
end of day Thursday.

Passed a-full on autobuilder:

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

The following changes since commit 46ba253059738dbd4de4bc7a7ac02a2585c498f5:

  vim: Upgrade 9.0.0341 -> 9.0.0453 (2022-09-14 08:08:22 -1000)

are available in the Git repository at:

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

Andrei Gherzan (1):
  qemu: Define libnfs PACKAGECONFIG

Chee Yang Lee (1):
  qemu: fix and ignore several CVEs

Hitendra Prajapati (1):
  connman: CVE-2022-32293 man-in-the-middle attack against a WISPR HTTP

Richard Purdie (1):
  qemu: Add PACKAGECONFIG for brlapi

Virendra Thakur (2):
  sqlite3: Fix CVE-2020-35525
  sqlite3: Fix CVE-2020-35527

 .../connman/connman/CVE-2022-32293.patch  | 266 ++
 .../connman/connman_1.37.bb   |   1 +
 meta/recipes-devtools/qemu/qemu.inc   |  17 ++
 .../qemu/qemu/CVE-2020-13754-1.patch  |  91 ++
 .../qemu/qemu/CVE-2020-13754-2.patch  |  69 +
 .../qemu/qemu/CVE-2020-13754-3.patch  |  65 +
 .../qemu/qemu/CVE-2020-13754-4.patch  |  39 +++
 .../qemu/qemu/CVE-2021-3713.patch |  67 +
 .../qemu/qemu/CVE-2021-3748.patch | 124 
 .../qemu/qemu/CVE-2021-3930.patch |  53 
 .../qemu/qemu/CVE-2021-4206.patch |  89 ++
 .../qemu/qemu/CVE-2021-4207.patch |  43 +++
 .../qemu/qemu/CVE-2022-0216-1.patch   |  42 +++
 .../qemu/qemu/CVE-2022-0216-2.patch   |  52 
 .../sqlite/files/CVE-2020-35525.patch |  21 ++
 .../sqlite/files/CVE-2020-35527.patch |  22 ++
 meta/recipes-support/sqlite/sqlite3_3.31.1.bb |   2 +
 17 files changed, 1063 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-3.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13754-4.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3713.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3930.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-4206.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-4207.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-0216-1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-0216-2.patch
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-35525.patch
 create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-35527.patch

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170920): 
https://lists.openembedded.org/g/openembedded-core/message/170920
Mute This Topic: https://lists.openembedded.org/mt/93819351/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] [yocto] QA notification for completed autobuilder build (yocto-4.0.4.rc1)

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-4.0.4.rc1. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone
 
ETA for completion next Monday, September 26.
 
Best regards,
Jing Hui



-Original Message-
From: yo...@lists.yoctoproject.org  On Behalf Of 
Pokybuild User
Sent: Wednesday, 21 September, 2022 7:09 AM
To: yo...@lists.yoctoproject.org
Cc: qa-build-notificat...@lists.yoctoproject.org
Subject: [yocto] QA notification for completed autobuilder build 
(yocto-4.0.4.rc1)


A build flagged for QA (yocto-4.0.4.rc1) was completed on the autobuilder and 
is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.0.4.rc1


Build hash information: 

bitbake: ac576d6fad6bba0cfea931883f25264ea83747ca
meta-agl: 2e8dbab520652afa5e39e74793bdc917aa9ee86b
meta-arm: 0a5eba13d81f5c5722a13b816193ebf93c0fd198
meta-aws: 3b4ce1c62e3d6fb7d4695e9b0c04bf7f922f051e
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: 01ad1a73aaab49d377d14bad8a7dec48f86cba83
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 8f96c05f6d82fde052f2cb1652c13922814accb0
meta-virtualization: 8c5f038cb92fa4b02246d2d1479a003eecf5fe93
oecore: f7766da462905ec67bf549d46b8017be36cd5b2a
poky: d64bef1c7d713b92a51228e5ade945835e5a94a4



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.pur...@linuxfoundation.org


 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170919): 
https://lists.openembedded.org/g/openembedded-core/message/170919
Mute This Topic: https://lists.openembedded.org/mt/93819316/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] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

On 9/20/22 5:39 AM, Richard Purdie wrote:

On Sat, 2022-09-17 at 14:13 -0700, Khem Raj wrote:

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

Signed-off-by: Khem Raj 
---
  .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
  meta/recipes-core/musl/gcompat_git.bb |  6 +-
  2 files changed, 63 insertions(+), 2 deletions(-)
  create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch


https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5873
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5890



Yeah my bad, Yoe distro uses usrmerge feature, and I forgot the main 
library is installed in base_libdir and not libdir, sent a v2 with this 
changed



Cheers,

Richard


OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170918): 
https://lists.openembedded.org/g/openembedded-core/message/170918
Mute This Topic: https://lists.openembedded.org/mt/93751127/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] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

Signed-off-by: Khem Raj 
---
v2: Symlink should point to base_libdir not libdir

 .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
 meta/recipes-core/musl/gcompat_git.bb |  6 +-
 2 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch

diff --git a/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch 
b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
new file mode 100644
index 00..ee292f3841
--- /dev/null
+++ b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
@@ -0,0 +1,59 @@
+From aecd42801904462501a890d173648e4e826eda19 Mon Sep 17 00:00:00 2001
+From: "A. Wilcox" 
+Date: Sat, 23 Oct 2021 23:29:40 -0500
+Subject: [PATCH] auxv: new module
+
+Adds `__getauxval` wrapper, needed for Parallels Tools GUI installer.
+
+Upstream-Status: Submitted 
[https://git.adelielinux.org/adelie/gcompat/-/commit/e860a38a88c7ea148ee15976136a1f83ea13f8e0]
+Signed-off-by: Khem Raj 
+---
+ CHANGELOG.rst | 5 +
+ Makefile  | 1 +
+ libgcompat/auxv.c | 6 ++
+ 3 files changed, 12 insertions(+)
+ create mode 100644 libgcompat/auxv.c
+
+diff --git a/CHANGELOG.rst b/CHANGELOG.rst
+index ce6859b..c3a9cee 100644
+--- a/CHANGELOG.rst
 b/CHANGELOG.rst
+@@ -11,6 +11,11 @@
+ 1.1 (202?-??-??)
+ 
+ 
++auxv
++
++
++* Add __getauxval wrapper for getauxval.
++
+ locale
+ --
+ 
+diff --git a/Makefile b/Makefile
+index cbb7634..1893cc1 100644
+--- a/Makefile
 b/Makefile
+@@ -2,6 +2,7 @@ LIBGCOMPAT_INCLUDE = \
+   libgcompat/alias.h \
+   libgcompat/internal.h
+ LIBGCOMPAT_SRC = \
++  libgcompat/auxv.c   \
+   libgcompat/ctype.c  \
+   libgcompat/cxx_thread.c \
+   libgcompat/dlfcn.c  \
+diff --git a/libgcompat/auxv.c b/libgcompat/auxv.c
+new file mode 100644
+index 000..01de376
+--- /dev/null
 b/libgcompat/auxv.c
+@@ -0,0 +1,6 @@
++#include  /* getauxval */
++
++unsigned long __getauxval(unsigned long value)
++{
++  return getauxval(value);
++}
+-- 
+2.37.3
+
diff --git a/meta/recipes-core/musl/gcompat_git.bb 
b/meta/recipes-core/musl/gcompat_git.bb
index b051e43b6c..773263809b 100644
--- a/meta/recipes-core/musl/gcompat_git.bb
+++ b/meta/recipes-core/musl/gcompat_git.bb
@@ -8,12 +8,13 @@ LICENSE = "NCSA"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=eb33ef4af05a9c7602843afb7adfe792"
 
 SRC_URI = 
"git://git.adelielinux.org/adelie/gcompat.git;protocol=https;branch=current \
-  "
+   file://0001-auxv-new-module.patch \
+   "
 SRC_URI:append:powerpc = "\
file://0001-make-Static-PIE-does-not-work-on-musl-ppc.patch \
"
 PV = "1.0.0+1.1+git${SRCPV}"
-SRCREV = "4d6a5156a6eb7f56b30d93853a872e36dadde81b"
+SRCREV = "c6921a1aa454bb87671f9bd1ecfe47d80d1620aa"
 
 S = "${WORKDIR}/git"
 
@@ -42,6 +43,7 @@ do_install () {
install -d ${D}${nonarch_base_libdir}${SITEINFO_BITS}
ln -rs ${D}${GLIBC_LDSO} 
${D}${nonarch_base_libdir}${SITEINFO_BITS}/`basename ${GLIBC_LDSO}`
fi
+   ln -sf ${base_libdir}/libgcompat.so.0 ${D}${libdir}/libgcompat.so
 }
 
 FILES:${PN} += "${nonarch_base_libdir}${SITEINFO_BITS}"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170917): 
https://lists.openembedded.org/g/openembedded-core/message/170917
Mute This Topic: https://lists.openembedded.org/mt/93819185/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 1/2 v2] rpm: Upgrade 4.17.1 -> 4.18rc1

[Richard Purdie]

On Wed, 2022-09-21 at 00:27 +0200, Alexander Kanavin wrote:
> Is it possible to submit fifofix.patch upstream while the issue is
> still 'hot' in your head? :) Should be just a github PR.

I had already done so and just forgotten to update the patch:

https://github.com/rpm-software-management/rpm/issues/2195

I did also realise just after sending and updated the patch to
Submitted. I opened an issue rather than a PR as I'm not entirely sure
upstream will like that fix and may want to do something different.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170916): 
https://lists.openembedded.org/g/openembedded-core/message/170916
Mute This Topic: https://lists.openembedded.org/mt/93814863/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 1/2 v2] rpm: Upgrade 4.17.1 -> 4.18rc1

[Alexander Kanavin]

Is it possible to submit fifofix.patch upstream while the issue is
still 'hot' in your head? :) Should be just a github PR.

Alex

On Wed, 21 Sept 2022 at 00:12, Richard Purdie
 wrote:
>
> rpm is close to release and give our release timings, update to the
> rc1 of 4.18.
>
> Includes fixes for CVE-2021-35937, CVE-2021-35938 and CVE-2021-35939
> which can't be easily backported.
>
> Add a PACKAGECONFIG option for a new readline dependency and disable
> it by default since it pulls in GPLv3 and that breaks a number of
> our test configurations as things stand.
>
> Refresh patches and drop the error.h patch as error() no longer used.
>
> Signed-off-by: Richard Purdie 
> ---
>  ...olor-setting-for-mips64_n32-binaries.patch | 22 +++---
>  ...satisfiable-dependency-when-building.patch | 10 +--
>  ...lib-rpm-as-the-installation-path-for.patch | 26 +++
>  ...1-Do-not-read-config-files-from-HOME.patch | 11 ++-
>  ...-PATH-environment-variable-before-ru.patch | 10 +--
>  ...lling-execute-package-scriptlets-wit.patch | 20 +++---
>  ...not-insert-payloadflags-into-.rpm-me.patch |  8 +--
>  ...-linux-gnux32-variant-to-triplet-han.patch | 17 ++---
>  ...o-not-build-manpages-requires-pandoc.patch | 11 ++-
>  c-fix-file-conflicts-for-MIPS64-N32.patch | 13 ++--
>  ...tools-Add-error.h-for-non-glibc-case.patch | 71 ---
>  ...prefixing-etc-from-RPM_ETCCONFIGDIR-.patch | 17 ++---
>  ...ge-logging-level-around-scriptlets-t.patch | 16 ++---
>  meta/recipes-devtools/rpm/files/fifofix.patch | 22 ++
>  meta/recipes-devtools/rpm/rpm_4.17.1.bb   | 10 ++-
>  15 files changed, 113 insertions(+), 171 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/rpm/files/0001-tools-Add-error.h-for-non-glibc-case.patch
>  create mode 100644 meta/recipes-devtools/rpm/files/fifofix.patch
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
> index 331ea849e69..9f5dde07205 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
> @@ -11,11 +11,11 @@ Signed-off-by: Alexander Kanavin 
>   rpmrc.in  | 2 ++
>   2 files changed, 6 insertions(+)
>
> -diff --git a/build/rpmfc.c b/build/rpmfc.c
> -index 10c380ee9..b7655aa93 100644
>  a/build/rpmfc.c
> -+++ b/build/rpmfc.c
> -@@ -639,6 +639,7 @@ exit:
> +Index: git/build/rpmfc.c
> +===
> +--- git.orig/build/rpmfc.c
>  git/build/rpmfc.c
> +@@ -645,6 +645,7 @@ exit:
>   static const struct rpmfcTokens_s rpmfcTokens[] = {
> { "directory",  RPMFC_INCLUDE },
>
> @@ -23,7 +23,7 @@ index 10c380ee9..b7655aa93 100644
> { "ELF 32-bit", RPMFC_ELF32|RPMFC_INCLUDE },
> { "ELF 64-bit", RPMFC_ELF64|RPMFC_INCLUDE },
>
> -@@ -1149,6 +1150,9 @@ static uint32_t getElfColor(const char *fn)
> +@@ -1150,6 +1151,9 @@ static uint32_t getElfColor(const char *
> color = RPMFC_ELF32;
> break;
> }
> @@ -33,11 +33,11 @@ index 10c380ee9..b7655aa93 100644
> elf_end(elf);
> }
> close(fd);
> -diff --git a/rpmrc.in b/rpmrc.in
> -index 5bd9ba3e5..f15bb8dad 100644
>  a/rpmrc.in
> -+++ b/rpmrc.in
> -@@ -137,6 +137,8 @@ archcolor: mipsr6el 1
> +Index: git/rpmrc.in
> +===
> +--- git.orig/rpmrc.in
>  git/rpmrc.in
> +@@ -139,6 +139,8 @@ archcolor: mipsr6el 1
>   archcolor: mips64r6 2
>   archcolor: mips64r6el 2
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> index 4029233fb70..8440c3516d6 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> @@ -14,11 +14,11 @@ Signed-off-by: Alexander Kanavin 
>   build/pack.c | 4 
>   1 file changed, 4 deletions(-)
>
> -diff --git a/build/pack.c b/build/pack.c
> -index e6cec1816..810cd7351 100644
>  a/build/pack.c
> -+++ b/build/pack.c
> -@@ -724,10 +724,6 @@ static rpmRC packageBinary(rpmSpec spec, Package pkg, 
> const char *cookie, int ch
> +Index: git/build/pack.c
> +===
> +--- git.orig/build/pack.c
>  git/build/pack.c
> +@@ -709,10 +709,6 @@ static rpmRC packageBinary(rpmSpec spec,
> headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, spec->sourcePkgId,16);
>   }
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
>  
> 

Re: [OE-core] [PATCH 2/2] perf: Fix for recent kernel upgrades

[Bruce Ashfield]

On Tue, Sep 20, 2022 at 6:12 PM Richard Purdie
 wrote:
>
> With recent kernel changes in stable, the full path to python was being
> encoded into binaries and python install files. Add some workarounds
> for both issues to fix build reproducibility issues.

Ack'd.

Looks good to me. I was looking into this, but had only barely figured
out what was being encoded .. much less fix.

Bruce

>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-kernel/perf/perf.bb | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 9f7c300a40e..31bc04635d8 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -145,6 +145,9 @@ do_install() {
> # we are checking for this make target to be compatible with older 
> perf versions
> if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true', 
> 'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
> oe_runmake DESTDIR=${D} install-python_ext
> +   if [ -e ${D}${libdir}/python*/site-packages/perf-*/SOURCES.txt ]; 
> then
> +   sed -i -e 's#${WORKDIR}##g' 
> ${D}${libdir}/python*/site-packages/perf-*/SOURCES.txt
> +   fi
> fi
>  }
>
> @@ -245,6 +248,9 @@ do_configure:prepend () {
>  # change the Makefile line to remove everything before 'tools/perf'
>  sed -i -e "s%srcdir_SQ = \$(subst ','\\\'',\$(srcdir))%srcdir_SQ = 
> \$(patsubst \%tools/perf,tools/perf,\$(subst ','\\\'',\$(srcdir)))%g" \
>  ${S}/tools/perf/Makefile.config
> +# Avoid hardcoded path to python-native
> +sed -i -e 's#\(PYTHON_WORD := \)$(call shell-wordify,$(PYTHON))#\1 
> python3#g' \
> +${S}/tools/perf/Makefile.config
>  fi
>  if [ -e "${S}/tools/perf/tests/Build" ]; then
>  # OUTPUT is the full path, we have python on the path so we remove 
> it from the
> --
> 2.34.1
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170914): 
https://lists.openembedded.org/g/openembedded-core/message/170914
Mute This Topic: https://lists.openembedded.org/mt/93814862/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] linux-yocto/5.19: cfg: fix ACPI warnings for -tiny

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/.:

acpi: fix defaults for x86 and qemuarm64

commit d334505d98a85ffe7549026d10e43cccd897e19c [efi.cfg: Drop ACPI 
dependency]
is generating configuration warnings on both qemuarm64 and x86 for the
poky-tiny configuration.

x864:
  - because we configure tiny with allnoconfig, and then apply our
fragments, the default of ACPI=y for x86 doesn't hold. We need
to exlicitly enable it. We put it in the x86 fragment, to avoid
bringing warnings back for arm32

ARM:
  - We can't assign to ARCH_SUPPORTS_ACPI, as that is a select only
value. The only selector for that config in arch/arm is CONFIG_EFI.
The default of CONFIG_ACPI was added to support EFI if required,
but since CONFIG_EFI takes care of the selection, we don't need it
in our BSP configuration.

Signed-off-by: Bruce Ashfield 
---

Richard,

This fixes the configuratino warnings on x86 and arm64 in my local
testing. I haven't run all archs yet, but wanted to get the patch
out after the first two came back clean.

This applies right on top of my previous series.

Bruce

 meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.19.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
index 29b7760298..17ae94066c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "359292dcf3fc078090666dc327d233695310"
-SRCREV_meta ?= "829511f25a4a868d33019ace607dc7f0a14d3105"
+SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.19;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
index 65b7070e6e..c18278ad79 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
@@ -15,7 +15,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
-SRCREV_meta ?= "829511f25a4a868d33019ace607dc7f0a14d3105"
+SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
index bafe57df0e..4fc1ae9245 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"44a446e91acea4f2f0d35896763224c3b52a3ed5"
 SRCREV_machine:qemux86-64 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
 SRCREV_machine:qemumips64 ?= "99613988297ac45653cc81319e63b2821645a3ba"
 SRCREV_machine ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
-SRCREV_meta ?= "829511f25a4a868d33019ace607dc7f0a14d3105"
+SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170913): 
https://lists.openembedded.org/g/openembedded-core/message/170913
Mute This Topic: https://lists.openembedded.org/mt/93814910/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 1/2 v2] rpm: Upgrade 4.17.1 -> 4.18rc1

[Richard Purdie]

rpm is close to release and give our release timings, update to the
rc1 of 4.18.

Includes fixes for CVE-2021-35937, CVE-2021-35938 and CVE-2021-35939
which can't be easily backported.

Add a PACKAGECONFIG option for a new readline dependency and disable
it by default since it pulls in GPLv3 and that breaks a number of
our test configurations as things stand.

Refresh patches and drop the error.h patch as error() no longer used.

Signed-off-by: Richard Purdie 
---
 ...olor-setting-for-mips64_n32-binaries.patch | 22 +++---
 ...satisfiable-dependency-when-building.patch | 10 +--
 ...lib-rpm-as-the-installation-path-for.patch | 26 +++
 ...1-Do-not-read-config-files-from-HOME.patch | 11 ++-
 ...-PATH-environment-variable-before-ru.patch | 10 +--
 ...lling-execute-package-scriptlets-wit.patch | 20 +++---
 ...not-insert-payloadflags-into-.rpm-me.patch |  8 +--
 ...-linux-gnux32-variant-to-triplet-han.patch | 17 ++---
 ...o-not-build-manpages-requires-pandoc.patch | 11 ++-
 c-fix-file-conflicts-for-MIPS64-N32.patch | 13 ++--
 ...tools-Add-error.h-for-non-glibc-case.patch | 71 ---
 ...prefixing-etc-from-RPM_ETCCONFIGDIR-.patch | 17 ++---
 ...ge-logging-level-around-scriptlets-t.patch | 16 ++---
 meta/recipes-devtools/rpm/files/fifofix.patch | 22 ++
 meta/recipes-devtools/rpm/rpm_4.17.1.bb   | 10 ++-
 15 files changed, 113 insertions(+), 171 deletions(-)
 delete mode 100644 
meta/recipes-devtools/rpm/files/0001-tools-Add-error.h-for-non-glibc-case.patch
 create mode 100644 meta/recipes-devtools/rpm/files/fifofix.patch

diff --git 
a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
 
b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
index 331ea849e69..9f5dde07205 100644
--- 
a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
+++ 
b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
@@ -11,11 +11,11 @@ Signed-off-by: Alexander Kanavin 
  rpmrc.in  | 2 ++
  2 files changed, 6 insertions(+)
 
-diff --git a/build/rpmfc.c b/build/rpmfc.c
-index 10c380ee9..b7655aa93 100644
 a/build/rpmfc.c
-+++ b/build/rpmfc.c
-@@ -639,6 +639,7 @@ exit:
+Index: git/build/rpmfc.c
+===
+--- git.orig/build/rpmfc.c
 git/build/rpmfc.c
+@@ -645,6 +645,7 @@ exit:
  static const struct rpmfcTokens_s rpmfcTokens[] = {
{ "directory",  RPMFC_INCLUDE },
  
@@ -23,7 +23,7 @@ index 10c380ee9..b7655aa93 100644
{ "ELF 32-bit", RPMFC_ELF32|RPMFC_INCLUDE },
{ "ELF 64-bit", RPMFC_ELF64|RPMFC_INCLUDE },
  
-@@ -1149,6 +1150,9 @@ static uint32_t getElfColor(const char *fn)
+@@ -1150,6 +1151,9 @@ static uint32_t getElfColor(const char *
color = RPMFC_ELF32;
break;
}
@@ -33,11 +33,11 @@ index 10c380ee9..b7655aa93 100644
elf_end(elf);
}
close(fd);
-diff --git a/rpmrc.in b/rpmrc.in
-index 5bd9ba3e5..f15bb8dad 100644
 a/rpmrc.in
-+++ b/rpmrc.in
-@@ -137,6 +137,8 @@ archcolor: mipsr6el 1
+Index: git/rpmrc.in
+===
+--- git.orig/rpmrc.in
 git/rpmrc.in
+@@ -139,6 +139,8 @@ archcolor: mipsr6el 1
  archcolor: mips64r6 2
  archcolor: mips64r6el 2
  
diff --git 
a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
 
b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
index 4029233fb70..8440c3516d6 100644
--- 
a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
+++ 
b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
@@ -14,11 +14,11 @@ Signed-off-by: Alexander Kanavin 
  build/pack.c | 4 
  1 file changed, 4 deletions(-)
 
-diff --git a/build/pack.c b/build/pack.c
-index e6cec1816..810cd7351 100644
 a/build/pack.c
-+++ b/build/pack.c
-@@ -724,10 +724,6 @@ static rpmRC packageBinary(rpmSpec spec, Package pkg, 
const char *cookie, int ch
+Index: git/build/pack.c
+===
+--- git.orig/build/pack.c
 git/build/pack.c
+@@ -709,10 +709,6 @@ static rpmRC packageBinary(rpmSpec spec,
headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, spec->sourcePkgId,16);
  }
  
diff --git 
a/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
 
b/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
index c6cf9d4c881..6f613d0a7d8 100644
--- 
a/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
+++ 
b/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
@@ -13,11 +13,11 @@ Signed-off-by: Alexander Kanavin 
  rpm.am   | 4 

[OE-core] [PATCH 2/2] perf: Fix for recent kernel upgrades

[Richard Purdie]

With recent kernel changes in stable, the full path to python was being
encoded into binaries and python install files. Add some workarounds
for both issues to fix build reproducibility issues.

Signed-off-by: Richard Purdie 
---
 meta/recipes-kernel/perf/perf.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 9f7c300a40e..31bc04635d8 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -145,6 +145,9 @@ do_install() {
# we are checking for this make target to be compatible with older perf 
versions
if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true', 'false', 
d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
oe_runmake DESTDIR=${D} install-python_ext
+   if [ -e ${D}${libdir}/python*/site-packages/perf-*/SOURCES.txt ]; 
then
+   sed -i -e 's#${WORKDIR}##g' 
${D}${libdir}/python*/site-packages/perf-*/SOURCES.txt
+   fi
fi
 }
 
@@ -245,6 +248,9 @@ do_configure:prepend () {
 # change the Makefile line to remove everything before 'tools/perf'
 sed -i -e "s%srcdir_SQ = \$(subst ','\\\'',\$(srcdir))%srcdir_SQ = 
\$(patsubst \%tools/perf,tools/perf,\$(subst ','\\\'',\$(srcdir)))%g" \
 ${S}/tools/perf/Makefile.config
+# Avoid hardcoded path to python-native
+sed -i -e 's#\(PYTHON_WORD := \)$(call shell-wordify,$(PYTHON))#\1 
python3#g' \
+${S}/tools/perf/Makefile.config
 fi
 if [ -e "${S}/tools/perf/tests/Build" ]; then
 # OUTPUT is the full path, we have python on the path so we remove it 
from the
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170911): 
https://lists.openembedded.org/g/openembedded-core/message/170911
Mute This Topic: https://lists.openembedded.org/mt/93814862/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] PR to fix WantedBy parsing of systemctl

[Alexandre Belloni via lists.openembedded.org]

Hello,

On 20/09/2022 17:55:42+, Robert Henz via lists.openembedded.org wrote:
> Hi everyone,
> 
> I have a PR to fix the WantedBy parsing of the systemctl script. I
> tried to follow the process described in your wiki
> (https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded),
> but ran into some problems I wasn't able to figure out. I will attach
> the patch file for my suggested change to this email but I also went
> ahead and created a fork and generated a GitHub PR in case that is
> ok/easier?

This is not easier to me. However, I'm interested to know more about the
issues you couldn't solve as this is a recurring topic.


> From 6cdb207ed99bc82324fb7b85126425ac8d439070 Mon Sep 17 00:00:00 2001
> From: Bob Henz 
> Date: Mon, 19 Sep 2022 22:02:58 -0400
> Subject: [PATCH] Fix WantedBy processing
> 
> An empty string assignment to WantedBy should clear all prior WantedBy
> settings. This matches behavior of the current systemd implementation.

Your SoB is missing here and this is mandatory.

> ---
>  meta/recipes-core/systemd/systemd-systemctl/systemctl | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
> b/meta/recipes-core/systemd/systemd-systemctl/systemctl
> index 6d19666d82..cddae75a06 100755
> --- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
> +++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
> @@ -26,6 +26,9 @@ locations = list()
>  
>  class SystemdFile():
>  """Class representing a single systemd configuration file"""
> +
> +_clearable_keys = ['WantedBy']
> +
>  def __init__(self, root, path, instance_unit_name):
>  self.sections = dict()
>  self._parse(root, path)
> @@ -80,6 +83,14 @@ class SystemdFile():
>  v = m.group('value')
>  if k not in section:
>  section[k] = list()
> +
> +# If we come across a "key=" line for a "clearable key", then
> +# forget all preceding assignments. This works because we are
> +# processing files in correct parse order.
> +if k in self._clearable_keys and not v:
> +del section[k]
> +continue
> +
>  section[k].extend(v.split())
>  
>  def get(self, section, prop):
> -- 
> 2.34.1
> 

> 
> 
> 


-- 
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 (#170910): 
https://lists.openembedded.org/g/openembedded-core/message/170910
Mute This Topic: https://lists.openembedded.org/mt/93809846/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] expat: CVE-2022-40674

[Florin Diaconescu]

Just saw the new release, I will submit another patch with the 2.4.9
upgrade. Thanks for letting me know!

Florin

On Tue, Sep 20, 2022 at 6:57 PM Alex Kiernan  wrote:

> 2.4.9 looks to have landed w/ this change in it.
>
> On Tue, Sep 20, 2022 at 12:09 PM Florin Diaconescu
>  wrote:
> >
> > Upstream-Status: Accepted
> > [
> https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b
> ]
> >
> > Signed-off-by: Florin Diaconescu 
> > ---
> >  .../expat/expat/CVE-2022-40674.patch  | 56 +++
> >  meta/recipes-core/expat/expat_2.4.8.bb|  1 +
> >  2 files changed, 57 insertions(+)
> >  create mode 100644 meta/recipes-core/expat/expat/CVE-2022-40674.patch
> >
> > diff --git a/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> > new file mode 100644
> > index 00..468811fefa
> > --- /dev/null
> > +++ b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> > @@ -0,0 +1,56 @@
> > +From 4a32da87e931ba54393d465bb77c40b5c33d343b Mon Sep 17 00:00:00 2001
> > +From: Rhodri James 
> > +Date: Wed, 17 Aug 2022 18:26:18 +0100
> > +Subject: [PATCH] Ensure raw tagnames are safe exiting
> internalEntityParser
> > +
> > +It is possible to concoct a situation in which parsing is
> > +suspended while substituting in an internal entity, so that
> > +XML_ResumeParser directly uses internalEntityProcessor as
> > +its processor.  If the subsequent parse includes some unclosed
> > +tags, this will return without calling storeRawNames to ensure
> > +that the raw versions of the tag names are stored in memory other
> > +than the parse buffer itself.  If the parse buffer is then changed
> > +or reallocated (for example if processing a file line by line),
> > +badness will ensue.
> > +
> > +This patch ensures storeRawNames is always called when needed
> > +after calling doContent.  The earlier call do doContent does
> > +not need the same protection; it only deals with entity
> > +substitution, which cannot leave unbalanced tags, and in any
> > +case the raw names will be pointing into the stored entity
> > +value not the parse buffer.
> > +
> > +CVE: CVE-2022-40674
> > +Upstream-Status: Accepted [
> https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b
> ]
> > +
> > +Signed-off-by: Florin Diaconescu 
> > +---
> > + lib/xmlparse.c | 13 +
> > + 1 file changed, 9 insertions(+), 4 deletions(-)
> > +
> > +diff --git a/lib/xmlparse.c b/lib/xmlparse.c
> > +index e986156..eabe0fc 100644
> > +--- a/lib/xmlparse.c
> >  b/lib/xmlparse.c
> > +@@ -5826,10 +5826,15 @@ internalEntityProcessor(XML_Parser parser,
> const char *s, const char *end,
> > +   {
> > + parser->m_processor = contentProcessor;
> > + /* see externalEntityContentProcessor vs contentProcessor */
> > +-return doContent(parser, parser->m_parentParser ? 1 : 0,
> parser->m_encoding,
> > +- s, end, nextPtr,
> > +- (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> > +- XML_ACCOUNT_DIRECT);
> > ++result = doContent(parser, parser->m_parentParser ? 1 : 0,
> > ++   parser->m_encoding, s, end, nextPtr,
> > ++   (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> > ++   XML_ACCOUNT_DIRECT);
> > ++if (result == XML_ERROR_NONE) {
> > ++  if (! storeRawNames(parser))
> > ++return XML_ERROR_NO_MEMORY;
> > ++}
> > ++return result;
> > +   }
> > + }
> > +
> > +--
> > +2.35.1
> > diff --git a/meta/recipes-core/expat/expat_2.4.8.bb
> b/meta/recipes-core/expat/expat_2.4.8.bb
> > index 980c488640..93a2f98b38 100644
> > --- a/meta/recipes-core/expat/expat_2.4.8.bb
> > +++ b/meta/recipes-core/expat/expat_2.4.8.bb
> > @@ -10,6 +10,7 @@ VERSION_TAG = "${@d.getVar('PV').replace('.', '_')}"
> >
> >  SRC_URI = "
> https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2
> \
> > file://run-ptest \
> > +   file://CVE-2022-40674.patch \
> > "
> >
> >  UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;
> > --
> > 2.25.1
> >
> >
> > 
> >
>
>
> --
> Alex Kiernan
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170909): 
https://lists.openembedded.org/g/openembedded-core/message/170909
Mute This Topic: https://lists.openembedded.org/mt/93800770/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 v1] meson: make wrapper options sub-command specific

[Alexandre Belloni via lists.openembedded.org]

Hello,

On 17/09/2022 18:07:35-0400, Liam Beguin wrote:
> The meson-wrapper adds setup options to facilitate cross-compilation.
> The current options are exclusive to the setup sub-command and might
> cause issues with other sub-commands.
> 
> Update the wrapper to make options sub-command specific.
> 

This caused many failures on the autobuilders:

buildepoxy.EpoxyTest.test_epoxy: ERROR (0.43s)

oeqa.utils.subprocesstweak.OETestCalledProcessError: Command '. 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato/1.0-r0/testimage-sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
 > /dev/null; meson -Degl=no -Dglx=no -Dx11=false 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato/1.0-r0/testimage-sdk/epoxybmd9dxec/build
 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato/1.0-r0/testimage-sdk/epoxybmd9dxec/libepoxy-1.5.3;'
 returned non-zero exit status 1
Standard Output: sed: -e expression #1, char 10: unknown option to `s'
ERROR: Neither directory contains a build file meson.build.

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5918/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5879/steps/12/logs/stdio
and others


> Signed-off-by: Liam Beguin 
> ---
>  .../meson/meson/meson-wrapper | 22 ---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper 
> b/meta/recipes-devtools/meson/meson/meson-wrapper
> index c62007f5077e..fae9e167a325 100755
> --- a/meta/recipes-devtools/meson/meson/meson-wrapper
> +++ b/meta/recipes-devtools/meson/meson/meson-wrapper
> @@ -13,7 +13,23 @@ fi
>  # config is already in meson.cross.
>  unset CC CXX CPP LD AR NM STRIP
>  
> +for arg in "${@}"; do
> +case ${arg} in
> +-*) continue ;;
> +*) SUBCMD=${arg}; break ;;
> +esac
> +done
> +
> +case ${SUBCMD} in
> +setup)
> +MESON_SUB_OPTS=" \
> +
> --cross-file="${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross"
>  \
> +
> --native-file="${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
> +"
> +;;
> +esac
> +
>  exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
> - --cross-file 
> "${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross" \
> - --native-file "${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
> - "$@"
> +${SUBCMD} \
> +${MESON_SUB_OPTS} \
> +$(echo $@ | sed s/${SUBCMD}//)
> 
> base-commit: 09c1cac053c2892e3af3250cc6229e8da78e7a50
> -- 
> 2.37.1.223.g6a475b71f8c4
> 

> 
> 
> 


-- 
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 (#170908): 
https://lists.openembedded.org/g/openembedded-core/message/170908
Mute This Topic: https://lists.openembedded.org/mt/93751917/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] expat: CVE-2022-40674

[Richard Purdie]

On Tue, 2022-09-20 at 13:39 +0300, Florin Diaconescu wrote:
> Upstream-Status: Accepted
> [https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
> 
> Signed-off-by: Florin Diaconescu 
> ---
>  .../expat/expat/CVE-2022-40674.patch  | 57 +++
>  meta/recipes-core/expat/expat_2.4.8.bb|  1 +
>  2 files changed, 58 insertions(+)
>  create mode 100644 meta/recipes-core/expat/expat/CVE-2022-40674.patch
> 
> diff --git a/meta/recipes-core/expat/expat/CVE-2022-40674.patch 
> b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> new file mode 100644
> index 00..3164edbb49
> --- /dev/null
> +++ b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> @@ -0,0 +1,57 @@
> +From 4a32da87e931ba54393d465bb77c40b5c33d343b Mon Sep 17 00:00:00 2001
> +From: Rhodri James 
> +Date: Wed, 17 Aug 2022 18:26:18 +0100
> +Subject: [PATCH] Ensure raw tagnames are safe exiting internalEntityParser
> +
> +It is possible to concoct a situation in which parsing is
> +suspended while substituting in an internal entity, so that
> +XML_ResumeParser directly uses internalEntityProcessor as
> +its processor.  If the subsequent parse includes some unclosed
> +tags, this will return without calling storeRawNames to ensure
> +that the raw versions of the tag names are stored in memory other
> +than the parse buffer itself.  If the parse buffer is then changed
> +or reallocated (for example if processing a file line by line),
> +badness will ensue.
> +
> +This patch ensures storeRawNames is always called when needed
> +after calling doContent.  The earlier call do doContent does
> +not need the same protection; it only deals with entity
> +substitution, which cannot leave unbalanced tags, and in any
> +case the raw names will be pointing into the stored entity
> +value not the parse buffer.
> +
> +CVE: CVE-2022-40674
> +Upstream-Status: Accepted 
> [https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
> +
> +Signed-off-by: Florin Diaconescu 
> +---
> + lib/xmlparse.c | 13 +
> + 1 file changed, 9 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/xmlparse.c b/lib/xmlparse.c
> +index e986156..eabe0fc 100644
> +--- a/lib/xmlparse.c
>  b/lib/xmlparse.c
> +@@ -5826,10 +5826,15 @@ internalEntityProcessor(XML_Parser parser, const 
> char *s, const char *end,
> +   {
> + parser->m_processor = contentProcessor;
> + /* see externalEntityContentProcessor vs contentProcessor */
> +-return doContent(parser, parser->m_parentParser ? 1 : 0, 
> parser->m_encoding,
> +- s, end, nextPtr,
> +- (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> +- XML_ACCOUNT_DIRECT);
> ++result = doContent(parser, parser->m_parentParser ? 1 : 0,
> ++   parser->m_encoding, s, end, nextPtr,
> ++   (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> ++   XML_ACCOUNT_DIRECT);
> ++if (result == XML_ERROR_NONE) {
> ++  if (! storeRawNames(parser))
> ++return XML_ERROR_NO_MEMORY;
> ++}
> ++return result;
> +   }
> + }
> + 
> +-- 
> +2.35.1
> +
> diff --git a/meta/recipes-core/expat/expat_2.4.8.bb 
> b/meta/recipes-core/expat/expat_2.4.8.bb
> index 980c488640..93a2f98b38 100644
> --- a/meta/recipes-core/expat/expat_2.4.8.bb
> +++ b/meta/recipes-core/expat/expat_2.4.8.bb
> @@ -10,6 +10,7 @@ VERSION_TAG = "${@d.getVar('PV').replace('.', '_')}"
>  
>  SRC_URI = 
> "https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2
>   \
> file://run-ptest \
> +   file://CVE-2022-40674.patch \
> "
>  
>  UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;

2.4.9 was just released to include this so I think an upgrade may be
prudent since I've not gotten this to testing yet?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170907): 
https://lists.openembedded.org/g/openembedded-core/message/170907
Mute This Topic: https://lists.openembedded.org/mt/93800443/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 0/9] kernel-yocto: consolidated pull request

[Bruce Ashfield]

On Tue, Sep 20, 2022 at 8:55 AM Richard Purdie
 wrote:
>
> On Tue, 2022-09-20 at 08:53 -0400, Bruce Ashfield wrote:
> > On Tue, Sep 20, 2022 at 8:22 AM Richard Purdie
> >  wrote:
> > >
> > > On Mon, 2022-09-19 at 10:28 -0400, bruce.ashfi...@gmail.com wrote:
> > > > From: Bruce Ashfield 
> > > >
> > > > Richard,
> > > >
> > > > Here's the next set of -stable updates to the active reference kernels.
> > > > I also have updates back to 5.4 that I'll send to the various stable
> > > > branches shortly.
> > > >
> > > > I also have a couple of kern-tools fixes. One to solve a problem 
> > > > reported
> > > > on the list about some directory structures (typically created from KAS)
> > > > to break the meta-data phase of the kernel build. I've fixed that issue,
> > > > then fixed the other regressions that fix caused, and have everything
> > > > passing sanity. There shouldn't be any fallout, but I'll be keeping a
> > > > close eye on things.
> > > >
> > > > I also have Khem's MDIO configuration change in the queue, along with
> > > > a previously hidden kern-tools feature that allows it to not warn if
> > > > something is 'enabled' (y or m).
> > >
> > > I have a patch in master-next I'm testing for the perf issue. On
> > > testing that, this set of config warnings became clear for poky-tiny:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157
> >
> > That's very likely due to this change from Andrei :
> > https://git.yoctoproject.org/yocto-kernel-cache/commit/?h=yocto-5.19=d334505d98a85ffe7549026d10e43cccd897e19c
> >
> > Was that a qemuarm64 configuration ?
>
> It warned on qemux86:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/12/logs/stdio
>
> qemux86-64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/16/logs/stdio
>
> qemuarm64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/18/logs/stdio
>
> so on all the arches we test for tiny.
>

I've reproduced it locally .. the fix is a bit fiddly. I'm going to
try some things tonight / tomorrow and will send a patch that goes
onto the end of the series to fix it up.

Bruce

> Cheers,
>
> Richard



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

[OE-core] PR to fix WantedBy parsing of systemctl

[Robert Henz via lists.openembedded.org]

Hi everyone,

I have a PR to fix the WantedBy parsing of the systemctl script. I tried to 
follow the process described in your wiki 
(https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded), but 
ran into some problems I wasn't able to figure out. I will attach the patch 
file for my suggested change to this email but I also went ahead and created a 
fork and generated a GitHub PR in case that is ok/easier?

https://github.com/openembedded/openembedded-core/pull/78

Again, I apologize for not being able to follow your defined procedure, please 
let me know if there is additional information you need from me.

Thanks,
Bob
From 6cdb207ed99bc82324fb7b85126425ac8d439070 Mon Sep 17 00:00:00 2001
From: Bob Henz 
Date: Mon, 19 Sep 2022 22:02:58 -0400
Subject: [PATCH] Fix WantedBy processing

An empty string assignment to WantedBy should clear all prior WantedBy
settings. This matches behavior of the current systemd implementation.
---
 meta/recipes-core/systemd/systemd-systemctl/systemctl | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index 6d19666d82..cddae75a06 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -26,6 +26,9 @@ locations = list()
 
 class SystemdFile():
 """Class representing a single systemd configuration file"""
+
+_clearable_keys = ['WantedBy']
+
 def __init__(self, root, path, instance_unit_name):
 self.sections = dict()
 self._parse(root, path)
@@ -80,6 +83,14 @@ class SystemdFile():
 v = m.group('value')
 if k not in section:
 section[k] = list()
+
+# If we come across a "key=" line for a "clearable key", then
+# forget all preceding assignments. This works because we are
+# processing files in correct parse order.
+if k in self._clearable_keys and not v:
+del section[k]
+continue
+
 section[k].extend(v.split())
 
 def get(self, section, prop):
-- 
2.34.1


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

[OE-core] Upstream checks and github

[Alex Kiernan]

It looks like something's changed in what github is returning on the
releases page which has broken `devtool latest-version` for recipes
which get their upstream data from that.

-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170904): 
https://lists.openembedded.org/g/openembedded-core/message/170904
Mute This Topic: https://lists.openembedded.org/mt/93808689/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] expat: CVE-2022-40674

[Alex Kiernan]

2.4.9 looks to have landed w/ this change in it.

On Tue, Sep 20, 2022 at 12:09 PM Florin Diaconescu
 wrote:
>
> Upstream-Status: Accepted
> [https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
>
> Signed-off-by: Florin Diaconescu 
> ---
>  .../expat/expat/CVE-2022-40674.patch  | 56 +++
>  meta/recipes-core/expat/expat_2.4.8.bb|  1 +
>  2 files changed, 57 insertions(+)
>  create mode 100644 meta/recipes-core/expat/expat/CVE-2022-40674.patch
>
> diff --git a/meta/recipes-core/expat/expat/CVE-2022-40674.patch 
> b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> new file mode 100644
> index 00..468811fefa
> --- /dev/null
> +++ b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
> @@ -0,0 +1,56 @@
> +From 4a32da87e931ba54393d465bb77c40b5c33d343b Mon Sep 17 00:00:00 2001
> +From: Rhodri James 
> +Date: Wed, 17 Aug 2022 18:26:18 +0100
> +Subject: [PATCH] Ensure raw tagnames are safe exiting internalEntityParser
> +
> +It is possible to concoct a situation in which parsing is
> +suspended while substituting in an internal entity, so that
> +XML_ResumeParser directly uses internalEntityProcessor as
> +its processor.  If the subsequent parse includes some unclosed
> +tags, this will return without calling storeRawNames to ensure
> +that the raw versions of the tag names are stored in memory other
> +than the parse buffer itself.  If the parse buffer is then changed
> +or reallocated (for example if processing a file line by line),
> +badness will ensue.
> +
> +This patch ensures storeRawNames is always called when needed
> +after calling doContent.  The earlier call do doContent does
> +not need the same protection; it only deals with entity
> +substitution, which cannot leave unbalanced tags, and in any
> +case the raw names will be pointing into the stored entity
> +value not the parse buffer.
> +
> +CVE: CVE-2022-40674
> +Upstream-Status: Accepted 
> [https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
> +
> +Signed-off-by: Florin Diaconescu 
> +---
> + lib/xmlparse.c | 13 +
> + 1 file changed, 9 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/xmlparse.c b/lib/xmlparse.c
> +index e986156..eabe0fc 100644
> +--- a/lib/xmlparse.c
>  b/lib/xmlparse.c
> +@@ -5826,10 +5826,15 @@ internalEntityProcessor(XML_Parser parser, const 
> char *s, const char *end,
> +   {
> + parser->m_processor = contentProcessor;
> + /* see externalEntityContentProcessor vs contentProcessor */
> +-return doContent(parser, parser->m_parentParser ? 1 : 0, 
> parser->m_encoding,
> +- s, end, nextPtr,
> +- (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> +- XML_ACCOUNT_DIRECT);
> ++result = doContent(parser, parser->m_parentParser ? 1 : 0,
> ++   parser->m_encoding, s, end, nextPtr,
> ++   (XML_Bool)! parser->m_parsingStatus.finalBuffer,
> ++   XML_ACCOUNT_DIRECT);
> ++if (result == XML_ERROR_NONE) {
> ++  if (! storeRawNames(parser))
> ++return XML_ERROR_NO_MEMORY;
> ++}
> ++return result;
> +   }
> + }
> +
> +--
> +2.35.1
> diff --git a/meta/recipes-core/expat/expat_2.4.8.bb 
> b/meta/recipes-core/expat/expat_2.4.8.bb
> index 980c488640..93a2f98b38 100644
> --- a/meta/recipes-core/expat/expat_2.4.8.bb
> +++ b/meta/recipes-core/expat/expat_2.4.8.bb
> @@ -10,6 +10,7 @@ VERSION_TAG = "${@d.getVar('PV').replace('.', '_')}"
>
>  SRC_URI = 
> "https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2
>   \
> file://run-ptest \
> +   file://CVE-2022-40674.patch \
> "
>
>  UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;
> --
> 2.25.1
>
>
> 
>


-- 
Alex Kiernan

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

[OE-core] Yocto Project Status 20 September 2022 (WW38)

[Stephen Jolley]

Current Dev Position: YP 4.1 M4 (Feature Freeze)

Next Deadline: 3rd October 2022 YP 4.1 M4 Build 

 

Next Team Meetings:

*   Bug Triage meeting Thursday September 22nd 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday September 20th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   4.1 M3 rc2 passed QA except for one issue from M2 we believed fixed
but which isn't.. We'll likely aim to fix that in M4 and release rc2 for M3
(pending TSC approval).
*   Last week was quieter as many people were in Dublin for ELC-E.
Thanks in particular to all who presented or otherwise helped with the booth
or other events there.
*   We've seen a good reduction in CVEs in dunfell and kirkstone but
master is still concerning. A number of the CVEs there have been reported
for version constraint issues to NIST.
*   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

 

Ways to contribute:

*   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 4.1. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.1_Unassigned_Enhan
cements.2FBugs
*   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/main
tainers.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 us resolve CVE issues:
 CVE metrics 

 

YP 4.1 Milestone Dates:

*   YP 4.1 M3 in review for release
*   YP 4.1 M4 build date 2022/10/03
*   YP 4.1 M4 Release date 2022/10/28

 

Upcoming dot releases:

*   YP 4.0.4 build date 2022/09/19
*   YP 4.0.4 Release date 2022/09/30
*   YP 3.1.20 build date 2022/10/10
*   YP 3.1.20 Release date 2022/10/21
*   YP 4.0.5 build date 2022/10/31
*   YP 4.0.5 Release date 2022/11/11

 

Tracking Metrics:

*   WDD 2409 (last week 2424) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1209 (last week 1209)
*   Patches in the Pending State: 311 (26%) [last week 311 (26%)]

*
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170902): 
https://lists.openembedded.org/g/openembedded-core/message/170902
Mute This Topic: https://lists.openembedded.org/mt/93805147/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] Adding more information to the SBOM

[Richard Purdie]

On Mon, 2022-09-19 at 16:20 +0200, Carlo Piana wrote:
> thank you for a well detailed and sensible answer. I certainly cannot
> speak on technical issues, although I can understand there are
> activities which could seriously impact the overall process and need
> to be minimized.
> 
> 
> > On Fri, 2022-09-16 at 17:18 +0200, Alberto Pianon wrote:
> > > Il 2022-09-15 14:16 Richard Purdie wrote:
> > > > 
> > > > For the source issues above it basically it comes down to how much
> > > > "pain" we want to push onto all users for the sake of adding in this
> > > > data. Unfortunately it is data which many won't need or use and
> > > > different legal departments do have different requirements.
> > > 
> > > We didn't paint the overall picture sufficiently well, therefore our
> > > requirements may come across as coming from a particularly pedantic
> > > legal department; my fault :)
> > > 
> > > Oniro is not "yet another commercial Yocto project", we are not a legal
> > > department (even if we are experienced FLOSS lawyers and auditors, the
> > > most prominent of whom is Carlo Piana -- cc'ed -- former general counsel
> > > of FSFE and member of OSI Board).
> > > 
> > > Our rather ambitious goal is not limited to Oniro, and consists in doing
> > > compliance in the open source way and both setting an example and
> > > providing guidance and material for others to benefit from our effort.
> > > Our work will therefore be shared (and possibly improved by others) not
> > > only with Oniro-based projects but also with any Yocto project. Among
> > > other things, the most relevant bit of work that we want to share is
> > > **fully reviewed license information** and other legal metadata about a
> > > whole bunch of open source components commonly used in Yocto projects.
> > 
> > I certainly love the goal. I presume you're going to share your review
> > criteria somehow? There must be some further set of steps,
> > documentation and results beyond what we're discussing here?
> 
> Our mandate (and our own attitude) is precisely to make everything as
> public as possible.
> 
> We have published already about it
> https://gitlab.eclipse.org/eclipse/oniro-compliancetoolchain/toolchain/docs/-/tree/main/audit_workflow
> 
> The entire review process is made using GitLab's issues and will be
> made public.

I need to read into the details but that looks like a great start and
I'm happy to see the process being documented!

Thanks for the link, I'll try and have a read.

> We have only one reservation concerning sensitive material
> in case we found something legally problematic (to comply with
> attorney/client privilege) or security-wise critic (in which case we
> adopt a responsible disclosure principle and embargo some details).

That makes sense, it is a tricky balancing act at times.

> > I think the challenge will be whether you can publish that review with
> > sufficient "proof" that other legal departments can leverage it. I
> > wouldn't underestimate how different the requirements and process can
> > be between different people/teams/companies.
> 
> Speaking from a legal perspective, this is precisely the point. It is
> true that we want to create a curated database of decisions, which as
> any human enterprise is prone to errors and correction and therefore
> we cannot have the last word. However, IF we can at least point to a
> unique artifact and give its exact hash, there will be no need to
> trust us, that would be open to inspection, because everybody else
> could look at the same source we have identified and make sure we
> have extracted all the information.

I do love the idea and I think it is quite possible. I do think this
does lead to one of the key details we need to think about though.

>From a legal perspective I'd imagine you like dealing with a set of
files that make up the source of some piece of software. I'm not going
to use the word "package" since I think the term is overloaded and
confusing. That set of files can all be identified by checksums. This
pushes us towards wanting checksums of every file.

Stepping over to the build world, we have bitbake's fetcher and it
actually requires something similar - any given "input" must be
uniquely identifiable from the SRC_URI and possibly a set of SRCREVs.

Why? We firstly need to embed this information into the task signature.
If it changes, we know we need to rerun the fetch and re-obtain the
data. We work on inputs to generate this hash, not outputs and we
require all fetcher modules to be able to identify sources like this.

In the case of a git repo, the hash of a git commit is good enough. For
a tarball, it would be a checksum of the tarball. Where there are patch
local files, we include the hashes of those files.

The bottom line is that we already have a hash which represents the
task inputs. Bugs happen, sure. There are also poor fetchers, npm and
go present challenges in particular but we've tried to work around
those issues.

What you're 

[OE-core] [dunfell][PATCH] connman: CVE-2022-32293 man-in-the-middle attack against a WISPR HTTP

[Hitendra Prajapati]

Source: https://git.kernel.org/pub/scm/network/connman/connman.git/
MR: 120508
Type: Security Fix
Disposition: Backport from 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=72343929836de80727a27d6744c869dff045757c
 && 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/src/wispr.c?id=416bfaff92c553c672e5bfc2d4f648d29e8a
ChangeID: 1583badc6de6bb8a7f63c06749b90b97caab5cdf
Description:
 CVE-2022-32293 connman: man-in-the-middle attack against a WISPR HTTP.

Signed-off-by: Hitendra Prajapati 
---
 .../connman/connman/CVE-2022-32293.patch  | 266 ++
 .../connman/connman_1.37.bb   |   1 +
 2 files changed, 267 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch

diff --git a/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch 
b/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch
new file mode 100644
index 00..83a013981c
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/CVE-2022-32293.patch
@@ -0,0 +1,266 @@
+From 358a44b1442fae0f82846e10da0708b5c4e1ce27 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Tue, 20 Sep 2022 17:58:19 +0530
+Subject: [PATCH] CVE-2022-32293
+
+CVE: CVE-2022-32293
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=72343929836de80727a27d6744c869dff045757c
 && 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/src/wispr.c?id=416bfaff92c553c672e5bfc2d4f648d29e8a]
+Signed-off-by: Hitendra Prajapati 
+---
+ src/wispr.c | 83 -
+ 1 file changed, 63 insertions(+), 20 deletions(-)
+
+diff --git a/src/wispr.c b/src/wispr.c
+index 473c0e0..97e0242 100644
+--- a/src/wispr.c
 b/src/wispr.c
+@@ -59,6 +59,7 @@ struct wispr_route {
+ };
+ 
+ struct connman_wispr_portal_context {
++  int refcount;
+   struct connman_service *service;
+   enum connman_ipconfig_type type;
+   struct connman_wispr_portal *wispr_portal;
+@@ -96,10 +97,13 @@ static bool wispr_portal_web_result(GWebResult *result, 
gpointer user_data);
+ 
+ static GHashTable *wispr_portal_list = NULL;
+ 
++#define wispr_portal_context_ref(wp_context) \
++  wispr_portal_context_ref_debug(wp_context, __FILE__, __LINE__, __func__)
++#define wispr_portal_context_unref(wp_context) \
++  wispr_portal_context_unref_debug(wp_context, __FILE__, __LINE__, 
__func__)
++
+ static void connman_wispr_message_init(struct connman_wispr_message *msg)
+ {
+-  DBG("");
+-
+   msg->has_error = false;
+   msg->current_element = NULL;
+ 
+@@ -159,11 +163,6 @@ static void free_wispr_routes(struct 
connman_wispr_portal_context *wp_context)
+ static void free_connman_wispr_portal_context(
+   struct connman_wispr_portal_context *wp_context)
+ {
+-  DBG("context %p", wp_context);
+-
+-  if (!wp_context)
+-  return;
+-
+   if (wp_context->wispr_portal) {
+   if (wp_context->wispr_portal->ipv4_context == wp_context)
+   wp_context->wispr_portal->ipv4_context = NULL;
+@@ -200,9 +199,38 @@ static void free_connman_wispr_portal_context(
+   g_free(wp_context);
+ }
+ 
++static struct connman_wispr_portal_context *
++wispr_portal_context_ref_debug(struct connman_wispr_portal_context 
*wp_context,
++  const char *file, int line, const char *caller)
++{
++  DBG("%p ref %d by %s:%d:%s()", wp_context,
++  wp_context->refcount + 1, file, line, caller);
++
++  __sync_fetch_and_add(_context->refcount, 1);
++
++  return wp_context;
++}
++
++static void wispr_portal_context_unref_debug(
++  struct connman_wispr_portal_context *wp_context,
++  const char *file, int line, const char *caller)
++{
++  if (!wp_context)
++  return;
++
++  DBG("%p ref %d by %s:%d:%s()", wp_context,
++  wp_context->refcount - 1, file, line, caller);
++
++  if (__sync_fetch_and_sub(_context->refcount, 1) != 1)
++  return;
++
++  free_connman_wispr_portal_context(wp_context);
++}
++
+ static struct connman_wispr_portal_context *create_wispr_portal_context(void)
+ {
+-  return g_try_new0(struct connman_wispr_portal_context, 1);
++  return wispr_portal_context_ref(
++  g_new0(struct connman_wispr_portal_context, 1));
+ }
+ 
+ static void free_connman_wispr_portal(gpointer data)
+@@ -214,8 +242,8 @@ static void free_connman_wispr_portal(gpointer data)
+   if (!wispr_portal)
+   return;
+ 
+-  free_connman_wispr_portal_context(wispr_portal->ipv4_context);
+-  free_connman_wispr_portal_context(wispr_portal->ipv6_context);
++  wispr_portal_context_unref(wispr_portal->ipv4_context);
++  wispr_portal_context_unref(wispr_portal->ipv6_context);
+ 
+   g_free(wispr_portal);
+ }
+@@ -450,8 +478,6 @@ static void portal_manage_status(GWebResult 

Re: [OE-core] [PATCH 0/9] kernel-yocto: consolidated pull request

[Richard Purdie]

On Tue, 2022-09-20 at 08:53 -0400, Bruce Ashfield wrote:
> On Tue, Sep 20, 2022 at 8:22 AM Richard Purdie
>  wrote:
> > 
> > On Mon, 2022-09-19 at 10:28 -0400, bruce.ashfi...@gmail.com wrote:
> > > From: Bruce Ashfield 
> > > 
> > > Richard,
> > > 
> > > Here's the next set of -stable updates to the active reference kernels.
> > > I also have updates back to 5.4 that I'll send to the various stable
> > > branches shortly.
> > > 
> > > I also have a couple of kern-tools fixes. One to solve a problem reported
> > > on the list about some directory structures (typically created from KAS)
> > > to break the meta-data phase of the kernel build. I've fixed that issue,
> > > then fixed the other regressions that fix caused, and have everything
> > > passing sanity. There shouldn't be any fallout, but I'll be keeping a
> > > close eye on things.
> > > 
> > > I also have Khem's MDIO configuration change in the queue, along with
> > > a previously hidden kern-tools feature that allows it to not warn if
> > > something is 'enabled' (y or m).
> > 
> > I have a patch in master-next I'm testing for the perf issue. On
> > testing that, this set of config warnings became clear for poky-tiny:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157
> 
> That's very likely due to this change from Andrei :
> https://git.yoctoproject.org/yocto-kernel-cache/commit/?h=yocto-5.19=d334505d98a85ffe7549026d10e43cccd897e19c
> 
> Was that a qemuarm64 configuration ?

It warned on qemux86:
https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/12/logs/stdio

qemux86-64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/16/logs/stdio

qemuarm64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157/steps/18/logs/stdio

so on all the arches we test for tiny.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170899): 
https://lists.openembedded.org/g/openembedded-core/message/170899
Mute This Topic: https://lists.openembedded.org/mt/93782003/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 0/9] kernel-yocto: consolidated pull request

[Bruce Ashfield]

On Tue, Sep 20, 2022 at 8:22 AM Richard Purdie
 wrote:
>
> On Mon, 2022-09-19 at 10:28 -0400, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield 
> >
> > Richard,
> >
> > Here's the next set of -stable updates to the active reference kernels.
> > I also have updates back to 5.4 that I'll send to the various stable
> > branches shortly.
> >
> > I also have a couple of kern-tools fixes. One to solve a problem reported
> > on the list about some directory structures (typically created from KAS)
> > to break the meta-data phase of the kernel build. I've fixed that issue,
> > then fixed the other regressions that fix caused, and have everything
> > passing sanity. There shouldn't be any fallout, but I'll be keeping a
> > close eye on things.
> >
> > I also have Khem's MDIO configuration change in the queue, along with
> > a previously hidden kern-tools feature that allows it to not warn if
> > something is 'enabled' (y or m).
>
> I have a patch in master-next I'm testing for the perf issue. On
> testing that, this set of config warnings became clear for poky-tiny:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157

That's very likely due to this change from Andrei :
https://git.yoctoproject.org/yocto-kernel-cache/commit/?h=yocto-5.19=d334505d98a85ffe7549026d10e43cccd897e19c

Was that a qemuarm64 configuration ?

Bruce


>
> Cheers,
>
> Richard



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170898): 
https://lists.openembedded.org/g/openembedded-core/message/170898
Mute This Topic: https://lists.openembedded.org/mt/93782003/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] Adding more information to the SBOM

[Alberto Pianon]

Il 2022-09-16 17:49 Mark Hatle wrote:

On 9/16/22 10:18 AM, Alberto Pianon wrote:

... trimmed ...

I also can see the issue with multiple sources in SRC_URI, although 
you
should be able to map those back if you assume subtrees are "owned" 
by

given SRC_URI entries. I suspect there may be a SPDX format limit in
documenting that piece?


I'm replying in reverse order:

- there is a SPDX format limit, but it is by design: a SPDX package
entity is a single sw distribution unit, so it may have only one
downloadLocation; if you have more than one downloadLocation, you 
must

have more than one SPDX package, according to SPDX specs;


I think my interpretation of this is different.  I've got a view of
'sourcing materials', and then verifying the are what we think they
are and can be used the way we want.  The "upstream sources" (and
patches) are really just 'raw materials' that we use the Yocto Project
to combined to create "the source".

So for the purpose of the SPDX, each upstream source _may_ have a
corresponding SPDX, but for the binaries their source is the combined
unit.. not multiple SPDXes.  Think of it something like:

upstream source1 - SPDX
upstream source2 - SPDX
upstream patch
recipe patch1
recipe patch2

In the above, each of those items would be combined by the recipe
system to construct the source used to build an individual recipe (and
collection of packages).  Automation _IS_ used to combine the
components [unpack/fetch] and _MAY_ be used to generated a combined
SPDX.

So your "upstream" location for this recipe is the local machine's
source archive.  The SPDX for the local recipe files can merge the
SPDX information they know (and if it's at a file level) can use
checksums to identify the items not captured/modified by the patches
for further review (either manual or automation like fossology).  In
the case where an upstream has SPDX data, you should be able to
inherit MOST files this way... but the output is specific to your
configuration and patches.

1 - SPDX |
2 - SPDX |
patch|---> recipe specific SPDX
patch|
patch|

In some cases someone may want to generate SPDX data for the 3
patches, but that may or may not be useful in this context.


IMHO it's a matter of different ways of framing Yocto recipes into SPDX
format.

Upstream sources are all SPDX packages. Yocto layers are SPDX packages,
too, containing some PATCH_FOR upstream packages.

Upstream sources and yocto layers are the "final" upstream sources, and
each of them has its downloadLocation.

"The source" created by a recipe is another SPDX package, GENERATED_FROM
upstream source packages + recipe and patches from Yocto layer
package(s). "The source" may need to be distributed by downstream users
(eg. to comply with *GPL-* obligations or when providing SDKs), so
downstream users may made it available from their own infrastructure,
"giving" it a downloadLocation.

(in SPDX, GENERATED_FROM and PATCH_FOR relationships may be between
files, so one may map files found in "the source" package to individual
files found in upstream source packages)

Binary packages GENERATED_FROM "the source" are local SPDX packages,
too. And firmware images are SPDX packages, too, GENERATED_FROM all the
above. Firmware images are distributed by downstream users, who will
provide their own downloadLocation.




- I understand that my solution is a bit hacky; but IMHO any other
*post-mortem* solution would be far more hacky; the real solution
would be collecting required information directly in do_fetch and
do_unpack


I've not looked at the current SPDX spec, but past versions has a
notes section.  Assuming this is still present you can use it to
reference back to how this component was constructed and the upstream
source URIs (and SPDX files) you used for processing.

This way nothing really changes in do_fetch or do_unpack.  (You may
want to find a way to capture file checksums and what the source was
for a particular file.. but it may not really be necessary!)



If you want to automatically map all files to their corresponding
upstram sources, it actually is... see my next point



- I also understand that we should reduce pain, otherwise nobody would
use our solution; the simplest and cleanest way I can think about 
is
collecting just package (in the SPDX sense) files' relative paths 
and
checksums at every stage (fetch, unpack, patch, package), and 
leave

data processing (i.e. mapping upstream source packages -> recipe's
WORKDIR package -> debug source package -> binary packages -> 
binary

image) to a separate tool, that may use (just a thought) a graph
database to process things more efficiently.


Even it do_patch nothing really changes, other then again you may want
to capture checksums to identify thingsthat need further processing.


This approach greatly simplifies things, and gives people doing code
reviews the insight into what is the source used when shipping the
binaries 

Re: [OE-core] [PATCH 0/9] kernel-yocto: consolidated pull request

[Richard Purdie]

On Mon, 2022-09-19 at 10:28 -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> Richard,
> 
> Here's the next set of -stable updates to the active reference kernels.
> I also have updates back to 5.4 that I'll send to the various stable
> branches shortly.
> 
> I also have a couple of kern-tools fixes. One to solve a problem reported
> on the list about some directory structures (typically created from KAS)
> to break the meta-data phase of the kernel build. I've fixed that issue,
> then fixed the other regressions that fix caused, and have everything
> passing sanity. There shouldn't be any fallout, but I'll be keeping a
> close eye on things.
> 
> I also have Khem's MDIO configuration change in the queue, along with
> a previously hidden kern-tools feature that allows it to not warn if
> something is 'enabled' (y or m).

I have a patch in master-next I'm testing for the perf issue. On
testing that, this set of config warnings became clear for poky-tiny:

https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6157

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170896): 
https://lists.openembedded.org/g/openembedded-core/message/170896
Mute This Topic: https://lists.openembedded.org/mt/93782003/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] python3-cryptography: workaround broken native functionality

[Richard Purdie]

On Tue, 2022-09-20 at 13:20 +0300, Mikko Rapeli wrote:
> Hi,
> 
> I created an issue in openssl about this:
> 
> https://github.com/openssl/openssl/issues/19242
> 
> Then I have the openssl patches in:
> 
> https://github.com/openssl/openssl/compare/master...mikkorapeli-linaro:openssl:relative_paths
> 
> The feedback so far is cold in upstream. Yes, the patches are a bit
> ugly too, but IMO so are the original code paths in openssl.
> I'll follow-up on openssl side if there is anything that could be
> improved. Comments and more feedback is welcome.
> 
> So what should we do now on oe side? python3-cryptography is
> completely broken and users really need to export at least
> 
> export OPENSSL_MODULES="${STAGING_LIBDIR_NATIVE}/ossl-modules"
> 
> or apply 
> https://github.com/openssl/openssl/commit/a10a6c298878cf438cc8c13f5878d97f476eb0d0
> to openssl-native.
> But that still leaves config files, engines and certificate paths broken.

Are there any other ways we could patch the code? Some ideas offhand
are:

a) the paths could be relative to the main library location?

b) the paths could have a token in them with is replaced with the
library path (a bit like $ORIGIN in RPATH)?

That might be more acceptable to upstream and be a bit less invasive?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170895): 
https://lists.openembedded.org/g/openembedded-core/message/170895
Mute This Topic: https://lists.openembedded.org/mt/93651845/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][PATCH] expat: CVE-2022-40674

[Florin Diaconescu]

Upstream-Status: Accepted
[https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]

Signed-off-by: Florin Diaconescu 
---
 .../expat/expat/CVE-2022-40674.patch  | 56 +++
 meta/recipes-core/expat/expat_2.4.8.bb|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-40674.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-40674.patch 
b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
new file mode 100644
index 00..468811fefa
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
@@ -0,0 +1,56 @@
+From 4a32da87e931ba54393d465bb77c40b5c33d343b Mon Sep 17 00:00:00 2001
+From: Rhodri James 
+Date: Wed, 17 Aug 2022 18:26:18 +0100
+Subject: [PATCH] Ensure raw tagnames are safe exiting internalEntityParser
+
+It is possible to concoct a situation in which parsing is
+suspended while substituting in an internal entity, so that
+XML_ResumeParser directly uses internalEntityProcessor as
+its processor.  If the subsequent parse includes some unclosed
+tags, this will return without calling storeRawNames to ensure
+that the raw versions of the tag names are stored in memory other
+than the parse buffer itself.  If the parse buffer is then changed
+or reallocated (for example if processing a file line by line),
+badness will ensue.
+
+This patch ensures storeRawNames is always called when needed
+after calling doContent.  The earlier call do doContent does
+not need the same protection; it only deals with entity
+substitution, which cannot leave unbalanced tags, and in any
+case the raw names will be pointing into the stored entity
+value not the parse buffer.
+
+CVE: CVE-2022-40674
+Upstream-Status: Accepted 
[https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
+
+Signed-off-by: Florin Diaconescu 
+---
+ lib/xmlparse.c | 13 +
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index e986156..eabe0fc 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -5826,10 +5826,15 @@ internalEntityProcessor(XML_Parser parser, const char 
*s, const char *end,
+   {
+ parser->m_processor = contentProcessor;
+ /* see externalEntityContentProcessor vs contentProcessor */
+-return doContent(parser, parser->m_parentParser ? 1 : 0, 
parser->m_encoding,
+- s, end, nextPtr,
+- (XML_Bool)! parser->m_parsingStatus.finalBuffer,
+- XML_ACCOUNT_DIRECT);
++result = doContent(parser, parser->m_parentParser ? 1 : 0,
++   parser->m_encoding, s, end, nextPtr,
++   (XML_Bool)! parser->m_parsingStatus.finalBuffer,
++   XML_ACCOUNT_DIRECT);
++if (result == XML_ERROR_NONE) {
++  if (! storeRawNames(parser))
++return XML_ERROR_NO_MEMORY;
++}
++return result;
+   }
+ }
+ 
+-- 
+2.35.1
diff --git a/meta/recipes-core/expat/expat_2.4.8.bb 
b/meta/recipes-core/expat/expat_2.4.8.bb
index 980c488640..93a2f98b38 100644
--- a/meta/recipes-core/expat/expat_2.4.8.bb
+++ b/meta/recipes-core/expat/expat_2.4.8.bb
@@ -10,6 +10,7 @@ VERSION_TAG = "${@d.getVar('PV').replace('.', '_')}"
 
 SRC_URI = 
"https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2
  \
file://run-ptest \
+   file://CVE-2022-40674.patch \
"
 
 UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170894): 
https://lists.openembedded.org/g/openembedded-core/message/170894
Mute This Topic: https://lists.openembedded.org/mt/93800770/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][PATCH] expat: upgrade 2.4.7 -> 2.4.8

[Florin Diaconescu]

Changelog:
=
 Other changes:
 #587  pkg-config: Move "-lm" to section "Libs.private"
 #587  CMake|MSVC: Fix pkg-config section "Libs"
 #55 #582  CMake|macOS: Start using linker arguments
 "-compatibility_version " and
 "-current_version " in a way compatible with
 GNU Libtool
 see https://verbump.de/ for what these numbers do

 Infrastructure:
 #589  CI: Upgrade Clang from 13 to 14

 Special thanks to:
 evpobr
 Kai Pastor
 Sam James

Signed-off-by: Florin Diaconescu 
---
 meta/recipes-core/expat/{expat_2.4.7.bb => expat_2.4.8.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-core/expat/{expat_2.4.7.bb => expat_2.4.8.bb} (91%)

diff --git a/meta/recipes-core/expat/expat_2.4.7.bb 
b/meta/recipes-core/expat/expat_2.4.8.bb
similarity index 91%
rename from meta/recipes-core/expat/expat_2.4.7.bb
rename to meta/recipes-core/expat/expat_2.4.8.bb
index bf1ca8d56e..980c488640 100644
--- a/meta/recipes-core/expat/expat_2.4.7.bb
+++ b/meta/recipes-core/expat/expat_2.4.8.bb
@@ -14,7 +14,7 @@ SRC_URI = 
"https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TA
 
 UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;
 
-SRC_URI[sha256sum] = 
"e149bdd8b90254c62b3d195da53a09bd531a4d63a963b0d8a5268d48dd2f6a65"
+SRC_URI[sha256sum] = 
"a247a7f6bbb21cf2ca81ea4cbb916bfb9717ca523631675f99b3d4a5678dcd16"
 
 EXTRA_OECMAKE:class-native += "-DEXPAT_BUILD_DOCS=OFF"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170893): 
https://lists.openembedded.org/g/openembedded-core/message/170893
Mute This Topic: https://lists.openembedded.org/mt/93800567/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] expat: CVE-2022-40674

[Florin Diaconescu]

Upstream-Status: Accepted
[https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]

Signed-off-by: Florin Diaconescu 
---
 .../expat/expat/CVE-2022-40674.patch  | 57 +++
 meta/recipes-core/expat/expat_2.4.8.bb|  1 +
 2 files changed, 58 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-40674.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-40674.patch 
b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
new file mode 100644
index 00..3164edbb49
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-40674.patch
@@ -0,0 +1,57 @@
+From 4a32da87e931ba54393d465bb77c40b5c33d343b Mon Sep 17 00:00:00 2001
+From: Rhodri James 
+Date: Wed, 17 Aug 2022 18:26:18 +0100
+Subject: [PATCH] Ensure raw tagnames are safe exiting internalEntityParser
+
+It is possible to concoct a situation in which parsing is
+suspended while substituting in an internal entity, so that
+XML_ResumeParser directly uses internalEntityProcessor as
+its processor.  If the subsequent parse includes some unclosed
+tags, this will return without calling storeRawNames to ensure
+that the raw versions of the tag names are stored in memory other
+than the parse buffer itself.  If the parse buffer is then changed
+or reallocated (for example if processing a file line by line),
+badness will ensue.
+
+This patch ensures storeRawNames is always called when needed
+after calling doContent.  The earlier call do doContent does
+not need the same protection; it only deals with entity
+substitution, which cannot leave unbalanced tags, and in any
+case the raw names will be pointing into the stored entity
+value not the parse buffer.
+
+CVE: CVE-2022-40674
+Upstream-Status: Accepted 
[https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b]
+
+Signed-off-by: Florin Diaconescu 
+---
+ lib/xmlparse.c | 13 +
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index e986156..eabe0fc 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -5826,10 +5826,15 @@ internalEntityProcessor(XML_Parser parser, const char 
*s, const char *end,
+   {
+ parser->m_processor = contentProcessor;
+ /* see externalEntityContentProcessor vs contentProcessor */
+-return doContent(parser, parser->m_parentParser ? 1 : 0, 
parser->m_encoding,
+- s, end, nextPtr,
+- (XML_Bool)! parser->m_parsingStatus.finalBuffer,
+- XML_ACCOUNT_DIRECT);
++result = doContent(parser, parser->m_parentParser ? 1 : 0,
++   parser->m_encoding, s, end, nextPtr,
++   (XML_Bool)! parser->m_parsingStatus.finalBuffer,
++   XML_ACCOUNT_DIRECT);
++if (result == XML_ERROR_NONE) {
++  if (! storeRawNames(parser))
++return XML_ERROR_NO_MEMORY;
++}
++return result;
+   }
+ }
+ 
+-- 
+2.35.1
+
diff --git a/meta/recipes-core/expat/expat_2.4.8.bb 
b/meta/recipes-core/expat/expat_2.4.8.bb
index 980c488640..93a2f98b38 100644
--- a/meta/recipes-core/expat/expat_2.4.8.bb
+++ b/meta/recipes-core/expat/expat_2.4.8.bb
@@ -10,6 +10,7 @@ VERSION_TAG = "${@d.getVar('PV').replace('.', '_')}"
 
 SRC_URI = 
"https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2
  \
file://run-ptest \
+   file://CVE-2022-40674.patch \
"
 
 UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/;
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170892): 
https://lists.openembedded.org/g/openembedded-core/message/170892
Mute This Topic: https://lists.openembedded.org/mt/93800443/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] python3-manifest.json: Add zoneinfo

[Leon Anavi]

The zoneinfo module provides a concrete time zone implementation
to support the IANA time zone database as originally specified in
PEP 615.

Signed-off-by: Leon Anavi 
---
 .../python/python3/python3-manifest.json  | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 2f5dad6486..2205cf2d2d 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1248,5 +1248,16 @@
 "${libdir}/python${PYTHON_MAJMIN}/xmlrpc/__pycache__"
 ],
 "cached": []
+},
+"zoneinfo": {
+"summary": "IANA time zone support",
+"rdepends": [
+"core"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/zoneinfo",
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_zoneinfo.*.so"
+],
+   "cached": []
 }
 }
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170891): 
https://lists.openembedded.org/g/openembedded-core/message/170891
Mute This Topic: https://lists.openembedded.org/mt/93800212/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] python3-cryptography: workaround broken native functionality

[Mikko Rapeli]

Hi,

I created an issue in openssl about this:

https://github.com/openssl/openssl/issues/19242

Then I have the openssl patches in:

https://github.com/openssl/openssl/compare/master...mikkorapeli-linaro:openssl:relative_paths

The feedback so far is cold in upstream. Yes, the patches are a bit
ugly too, but IMO so are the original code paths in openssl.
I'll follow-up on openssl side if there is anything that could be
improved. Comments and more feedback is welcome.

So what should we do now on oe side? python3-cryptography is
completely broken and users really need to export at least

export OPENSSL_MODULES="${STAGING_LIBDIR_NATIVE}/ossl-modules"

or apply 
https://github.com/openssl/openssl/commit/a10a6c298878cf438cc8c13f5878d97f476eb0d0
to openssl-native.
But that still leaves config files, engines and certificate paths broken.

Cheers,
-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170890): 
https://lists.openembedded.org/g/openembedded-core/message/170890
Mute This Topic: https://lists.openembedded.org/mt/93651845/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 0/9] kernel-yocto: consolidated pull request

[Richard Purdie]

On Mon, 2022-09-19 at 10:28 -0400, bruce.ashfi...@gmail.com wrote:
> Here's the next set of -stable updates to the active reference kernels.
> I also have updates back to 5.4 that I'll send to the various stable
> branches shortly.
> 
> I also have a couple of kern-tools fixes. One to solve a problem reported
> on the list about some directory structures (typically created from KAS)
> to break the meta-data phase of the kernel build. I've fixed that issue,
> then fixed the other regressions that fix caused, and have everything
> passing sanity. There shouldn't be any fallout, but I'll be keeping a
> close eye on things.
> 
> I also have Khem's MDIO configuration change in the queue, along with
> a previously hidden kern-tools feature that allows it to not warn if
> something is 'enabled' (y or m).

Thanks, those sound like good fixes. Unfortunately this showed an issue
with TMPDIR in perf somewhere in testing:

Reproducible error:
https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/1570

and warnings:
https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/5871

https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5832
https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5862
https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/6153
https://autobuilder.yoctoproject.org/typhoon/#/builders/131/builds/1255
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5848
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5910
and more, seems to be on all arches.

Diffoscope output is here:
http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20220919-7ypfzvog/packages/diff-html/

which shows an issue in debug symbols and it looks to be python
related:

PYTHON·BUILD_STR('/home/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleA/tmp/work/qemux86_64-poky-linux/perf/1.0-r9/recipe-sysroot-native/usr/bin/python3-native/python3')

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170889): 
https://lists.openembedded.org/g/openembedded-core/message/170889
Mute This Topic: https://lists.openembedded.org/mt/93782003/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] gcompat: Add __getauxval wrapper needed on aarch64

[Richard Purdie]

On Sat, 2022-09-17 at 14:13 -0700, Khem Raj wrote:
> Update SRCREV to bring in few bug fixes
> Install a .so symlink which could be used during linking
> 
> Signed-off-by: Khem Raj 
> ---
>  .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
>  meta/recipes-core/musl/gcompat_git.bb |  6 +-
>  2 files changed, 63 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5873
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5890

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170888): 
https://lists.openembedded.org/g/openembedded-core/message/170888
Mute This Topic: https://lists.openembedded.org/mt/93751127/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] [docs] [PATCH 1/7] common-tasks.rst: remove SRC_URI:append from examples

[Mikko Rapeli]

Hi,

On Mon, 19 Sept 2022 at 23:35, Michael Opdenacker
 wrote:
>
> Mikko, thanks for the patch series.
> Quentin, thanks for the review.
>
> Indeed, I think that the description of the commit should be improved
> too. See below.
>
> On 9/19/22 16:04, Quentin Schulz via lists.openembedded.org wrote:
> > Hi Mikko,
> >
> > On 9/12/22 09:32, Mikko Rapeli wrote:
> >> Using SRC_URI:append without recipe, machine or architecture
> >> specific limitations makes the :append'ed text unremovable
> >> and thus users and custom layers can not change the variable
> >> anymore. This makes it hard to e.g. override SRC_URI completely
> >> in a bbappend to update the full recipe to a newer version.
> >> Thus common, reusable layers which users are meant to re-use and
> >> customize should not use SRC_URI:append but SRC_URI += instead.
>
>
> What the following text instead?
>
> Using SRC_URI:append without recipe, machine or architecture specific
> limitations makes the :append'ed text more difficult to override than if
> the "+=" operator was used. This makes it hard for example to override
> SRC_URI completely in a bbappend to update the full recipe to a newer
> version. Thus common, reusable layers which users are meant to re-use
> and customize should not use SRC_URI:append but SRC_URI += instead.

Ok, will send a v2 with this.

> >>
> >> Signed-off-by: Mikko Rapeli 
> >> ---
> >>   documentation/dev-manual/common-tasks.rst | 9 +
> >>   1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/documentation/dev-manual/common-tasks.rst
> >> b/documentation/dev-manual/common-tasks.rst
> >> index b08a55331d..3112f9b893 100644
> >> --- a/documentation/dev-manual/common-tasks.rst
> >> +++ b/documentation/dev-manual/common-tasks.rst
> >> @@ -2577,7 +2577,7 @@ chapter of the BitBake User Manual.
> >>   S = "${WORKDIR}/postfix-${PV}"
> >> CFLAGS += "-DNO_ASM"
> >> -  SRC_URI:append = " file://fixup.patch"
> >> +  CFLAGS:append = " --enable-important-feature"
>
>
> Didn't you mean
> + SRC_URI += "file://fixup.patch"
>
> instead here?

No. The sample code shows how to use variables so it needs an :append example
but SRC_URI is not good use for :append's. Hence I changed it to CFLAGS:append.

> >> -  *Functions:* Functions provide a series of actions to be
> >> performed.
> >>  You usually use functions to override the default implementation
> >> of a
> >> @@ -2708,19 +2708,20 @@ in the BitBake User Manual.
> >>  to existing variables. This operator does not add any additional
> >>  space. Also, the operator is applied after all the ``+=``, and
> >> ``=+``
> >>  operators have been applied and after all ``=`` assignments have
> >> -   occurred.
> >> +   occurred. This means that if ``:append`` is used, that text can
> >> not be
> >> +   removed.
> >
> > Pedantic: it can, with :remove. One should try really hard to not use
> > it though.
>
>
> What about...
>
> "This means that if ``:append`` is used in a recipe, it cannot only be
> overridden by another layer using the  special ``:remove`` operator,
> which in turn will prevent further layers from adding it back."
>
> I'm not very happy with this wording, because ":remove" hasn't been
> introduced at this stage in this section. Maybe we should add a link
> to 
> https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-syntax-overrides
>
> Any thoughts?

I'll send v2 with this version.

I'd like to get rid of all SRC_URI:append's in documentation
since that bad practice already ended in various recipes in poky master
and kirkstone branches.

Cheers,
-Mikko

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