* [OE-core][scarthgap][PATCH 3/3] ca-certificates: upgrade 20260223 -> 20260601
From: ankur.tyagi85 @ 2026-07-20 4:23 UTC (permalink / raw)
To: openembedded-core; +Cc: Ankur Tyagi, Richard Purdie
In-Reply-To: <20260720042344.695725-1-ankur.tyagi85@gmail.com>
From: Ankur Tyagi <ankur.tyagi85@gmail.com>
License-Update: ca-certificates-local example removed[1]
[1] https://salsa.debian.org/debian/ca-certificates/-/commit/0ba2e089daf128206b0a13423ceede612bb60270
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 366cfc1103661f98020d7b7c8d249f2b7f9432af)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
---
...a-certificates_20260223.bb => ca-certificates_20260601.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/ca-certificates/{ca-certificates_20260223.bb => ca-certificates_20260601.bb} (94%)
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20260223.bb b/meta/recipes-support/ca-certificates/ca-certificates_20260601.bb
similarity index 94%
rename from meta/recipes-support/ca-certificates/ca-certificates_20260223.bb
rename to meta/recipes-support/ca-certificates/ca-certificates_20260601.bb
index 9cf6d5afc7..b23f20a782 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20260223.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20260601.bb
@@ -5,7 +5,7 @@ This derived from Debian's CA Certificates."
HOMEPAGE = "http://packages.debian.org/sid/ca-certificates"
SECTION = "misc"
LICENSE = "GPL-2.0-or-later & MPL-2.0"
-LIC_FILES_CHKSUM = "file://debian/copyright;md5=ae5b36b514e3f12ce1aa8e2ee67f3d7e"
+LIC_FILES_CHKSUM = "file://debian/copyright;md5=dab7c7cea776d1a1648deb0052c72647"
# This is needed to ensure we can run the postinst at image creation time
DEPENDS = ""
@@ -14,7 +14,7 @@ DEPENDS:class-nativesdk = "openssl-native"
# Need rehash from openssl and run-parts from debianutils
PACKAGE_WRITE_DEPS += "openssl-native debianutils-native"
-SRC_URI[sha256sum] = "2fa2b00d4360f0d14ec51640ae8aea9e563956b95ea786e3c3c01c4eead42b56"
+SRC_URI[sha256sum] = "7ab6301f7f34eef90a4d278647c260bc0762e0e14561f4649854cf4b0d4bea21"
SRC_URI = "${DEBIAN_MIRROR}/main/c/ca-certificates/${BPN}_${PV}.tar.xz \
file://0001-update-ca-certificates-don-t-use-Debianisms-in-run-p.patch \
file://0003-update-ca-certificates-use-relative-symlinks-from-ET.patch \
^ permalink raw reply related
* [OE-core][scarthgap][PATCH 1/3] wireless-regdb: upgrade 2026.02.04 -> 2026.03.18
From: ankur.tyagi85 @ 2026-07-20 4:23 UTC (permalink / raw)
To: openembedded-core; +Cc: Ankur Tyagi, Richard Purdie
From: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 97a940bfdeaa3f9f4442a6fbb0fabe1ce5eaff69)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
---
...ireless-regdb_2026.02.04.bb => wireless-regdb_2026.03.18.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2026.02.04.bb => wireless-regdb_2026.03.18.bb} (94%)
diff --git a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.02.04.bb b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.03.18.bb
similarity index 94%
rename from meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.02.04.bb
rename to meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.03.18.bb
index 2f7c816043..a70e9dd0da 100644
--- a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.02.04.bb
+++ b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2026.03.18.bb
@@ -5,7 +5,7 @@ LICENSE = "ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=07c4f6dea3845b02a18dc00c8c87699c"
SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz"
-SRC_URI[sha256sum] = "0ff48a5cd9e9cfe8e815a24e023734919e9a3b7ad2f039243ad121cf5aabf6c6"
+SRC_URI[sha256sum] = "5fc0000475d8c5368ccc5222827c16aef98b1eb6a69c9b5a3e7b7e98528945ac"
inherit bin_package allarch
^ permalink raw reply related
* Re: [OE-core][scarthgap][PATCH 1/6] glib-2.0: fix CVE-2026-58010
From: Yoann Congal @ 2026-07-19 22:56 UTC (permalink / raw)
To: deeratho, openembedded-core
In-Reply-To: <20260715172330.1149253-1-deeratho@cisco.com>
On Wed Jul 15, 2026 at 7:23 PM CEST, Deepak Rathore via lists.openembedded.org wrote:
> From: Deepak Rathore <deeratho@cisco.com>
>
> This patch applies the upstream 2.86.5 backport for
> CVE-2026-58010. The upstream fix commit is referenced in [1],
> and the public CVE advisory is referenced in [2].
>
> [1] https://gitlab.gnome.org/GNOME/glib/-/commit/aa1cb87d56111ef989811e824f0ac77484cc997f
> [2] https://nvd.nist.gov/vuln/detail/CVE-2026-58010
>
> Signed-off-by: Deepak Rathore <deeratho@cisco.com>
Hello,
FYI, I will merge [wrynose][PATCH] glib-2.0: upgrade 2.88.0 -> 2.88.2
https://lore.kernel.org/openembedded-core/20260719221822.3458326-1-peter.marko@siemens.com/T/#u
first, then this series.
Thanks!
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core][wrynose][PATCH 1/6] glib-2.0: Fix CVE-2026-58010
From: Yoann Congal @ 2026-07-19 22:23 UTC (permalink / raw)
To: Marko, Peter, deeratho@cisco.com,
openembedded-core@lists.openembedded.org
In-Reply-To: <AS8PR10MB507315DE4004CB2A27B81297FDC42@AS8PR10MB5073.EURPRD10.PROD.OUTLOOK.COM>
On Mon Jul 20, 2026 at 12:20 AM CEST, Peter Marko wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Yoann Congal via
>> lists.openembedded.org
>> Sent: Friday, July 17, 2026 5:46 PM
>> To: deeratho@cisco.com; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core][wrynose][PATCH 1/6] glib-2.0: Fix CVE-2026-58010
>>
>> On Wed Jul 15, 2026 at 7:21 PM CEST, Deepak Rathore via lists.openembedded.org
>> wrote:
>> > From: Deepak Rathore <deeratho@cisco.com>
>> >
>> > This patch applies the upstream 2.88.1 backport for
>> > CVE-2026-58010. The upstream fix commit is referenced in [1],
>> > and the public CVE advisory is referenced in [2].
>> >
>> > [1] https://gitlab.gnome.org/GNOME/glib/-
>> /commit/be85f9429bb66412a9775440a88cb115803ba897
>> > [2] https://nvd.nist.gov/vuln/detail/CVE-2026-58010
>> >
>> > Signed-off-by: Deepak Rathore <deeratho@cisco.com>
>>
>> Hello Deepak and Adarsh,
>>
>> You both sent backport patches for this CVE.
>>
>> This CVE (and I bet others of this series) can be fixed by upgrading
>> along the 2.88.x branch of glib. There are precedent for glib upgrade on
>> stable branches.
>>
>> Can you look into the glib changelog and see if there are changes
>> incompatible with our policy?
>
> Hello Yoann,
> I have sent an upgrade patch.
> Peter
Sounds good!
Thanks Peter!
>
>>
>> If upgrading is compatible, please tell me and I will cherry pick the
>> upgrades from master:
>> glib-2.0: Upgrade 2.88.0 -> 2.88.1
>> https://git.openembedded.org/openembedded-
>> core/commit/?id=e2063c252d1ab3188e74e9eced91bc17463d6551
>> glib-2.0: upgrade 2.88.1 -> 2.88.2
>> https://git.openembedded.org/openembedded-
>> core/commit/?id=c22a7bd7ecb463da212c25a5aa81a19992e17e1c
>>
>> If not, ping me as well, I will then resume reviewing this series.
>>
>> Regards,
>> --
>> Yoann Congal
>> Smile ECS
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core][scarthgap][PATCH v2] libpng: Fix CVE-2026-34757
From: Yoann Congal @ 2026-07-19 22:21 UTC (permalink / raw)
To: sudumbha, openembedded-core
In-Reply-To: <20260714134636.2883793-2-sudumbha@cisco.com>
On Tue Jul 14, 2026 at 3:46 PM CEST, Sudhir Dumbhare via lists.openembedded.org wrote:
> From: Sudhir Dumbhare <sudumbha@cisco.com>
>
> These patches apply the upstream fixes [1][2], which address
> getter-to-setter aliasing issues in libpng chunk setters that could
> cause stale-pointer reads, as described in [3].
>
> [1] https://github.com/pnggroup/libpng/commit/398cbe3df03f4e11bb031e07f416dfdde3684e8a
> [2] https://github.com/pnggroup/libpng/commit/55d20aaa322c9274491cda82c5cd4f99b48c6bcc
> [3] https://github.com/pnggroup/libpng/issues/836
>
> Reference:
> https://security-tracker.debian.org/tracker/CVE-2026-34757
> https://nvd.nist.gov/vuln/detail/CVE-2026-34757
>
> Test results on qemux86-64 using ptest-runner:
> START: ptest-runner
> 2026-06-04T11:29
> BEGIN: /usr/lib/libpng/ptest
> PASS: tests/pnggetset
> Testsuite summary
> # TOTAL: 33
> # PASS: 33
> # SKIP: 0
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
> DURATION: 80
> END: /usr/lib/libpng/ptest
> 2026-06-04T11:31
> STOP: ptest-runner
> TOTAL: 1 FAIL: 0
>
> Signed-off-by: Sudhir Dumbhare <sudumbha@cisco.com>
> ---
> Changes v1 -> v2:
> - Rebased on latest scarthgap (2bf388381ae3)
>
> .../libpng/files/CVE-2026-34757_p1.patch | 521 ++++++++++++++++++
> .../libpng/files/CVE-2026-34757_p2.patch | 484 ++++++++++++++++
> .../libpng/libpng_1.6.42.bb | 4 +-
> 3 files changed, 1008 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-multimedia/libpng/files/CVE-2026-34757_p1.patch
> create mode 100644 meta/recipes-multimedia/libpng/files/CVE-2026-34757_p2.patch
As fas as I can tell, this patch is also needed on wrynose.
I can't merge here until this is fixed on wrynose.
Can you send a patch to fix this and then, ping back here?
Thanks!
--
Yoann Congal
Smile ECS
^ permalink raw reply
* RE: [OE-core][wrynose][PATCH 1/6] glib-2.0: Fix CVE-2026-58010
From: Marko, Peter @ 2026-07-19 22:20 UTC (permalink / raw)
To: yoann.congal@smile.fr, deeratho@cisco.com,
openembedded-core@lists.openembedded.org
In-Reply-To: <DK0YOQ6AB7SY.CQYLAG61QCB@smile.fr>
> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Yoann Congal via
> lists.openembedded.org
> Sent: Friday, July 17, 2026 5:46 PM
> To: deeratho@cisco.com; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][wrynose][PATCH 1/6] glib-2.0: Fix CVE-2026-58010
>
> On Wed Jul 15, 2026 at 7:21 PM CEST, Deepak Rathore via lists.openembedded.org
> wrote:
> > From: Deepak Rathore <deeratho@cisco.com>
> >
> > This patch applies the upstream 2.88.1 backport for
> > CVE-2026-58010. The upstream fix commit is referenced in [1],
> > and the public CVE advisory is referenced in [2].
> >
> > [1] https://gitlab.gnome.org/GNOME/glib/-
> /commit/be85f9429bb66412a9775440a88cb115803ba897
> > [2] https://nvd.nist.gov/vuln/detail/CVE-2026-58010
> >
> > Signed-off-by: Deepak Rathore <deeratho@cisco.com>
>
> Hello Deepak and Adarsh,
>
> You both sent backport patches for this CVE.
>
> This CVE (and I bet others of this series) can be fixed by upgrading
> along the 2.88.x branch of glib. There are precedent for glib upgrade on
> stable branches.
>
> Can you look into the glib changelog and see if there are changes
> incompatible with our policy?
Hello Yoann,
I have sent an upgrade patch.
Peter
>
> If upgrading is compatible, please tell me and I will cherry pick the
> upgrades from master:
> glib-2.0: Upgrade 2.88.0 -> 2.88.1
> https://git.openembedded.org/openembedded-
> core/commit/?id=e2063c252d1ab3188e74e9eced91bc17463d6551
> glib-2.0: upgrade 2.88.1 -> 2.88.2
> https://git.openembedded.org/openembedded-
> core/commit/?id=c22a7bd7ecb463da212c25a5aa81a19992e17e1c
>
> If not, ping me as well, I will then resume reviewing this series.
>
> Regards,
> --
> Yoann Congal
> Smile ECS
^ permalink raw reply
* [wrynose][PATCH] glib-2.0: upgrade 2.88.0 -> 2.88.2
From: Peter Marko @ 2026-07-19 22:18 UTC (permalink / raw)
To: openembedded-core; +Cc: Peter Marko
Refresh patches via devtool.
Release notes: [1] and [2].
2.88.1: Fix various minor (low severity) security issues
CVE-2026-58010, CVE-2026-58011, CVE-2026-58012, CVE-2026-58013,
CVE-2026-58014 and CVE-2026-58015
[1] https://gitlab.gnome.org/GNOME/glib/-/releases/2.88.1
[2] https://gitlab.gnome.org/GNOME/glib/-/releases/2.88.2
Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
.../glib-2.0/files/CVE-2026-58016-1.patch | 12 ++++----
.../glib-2.0/files/CVE-2026-58016-2.patch | 30 +++++++++----------
...l_2.88.0.bb => glib-2.0-initial_2.88.2.bb} | 0
...{glib-2.0_2.88.0.bb => glib-2.0_2.88.2.bb} | 0
meta/recipes-core/glib-2.0/glib.inc | 2 +-
5 files changed, 22 insertions(+), 22 deletions(-)
rename meta/recipes-core/glib-2.0/{glib-2.0-initial_2.88.0.bb => glib-2.0-initial_2.88.2.bb} (100%)
rename meta/recipes-core/glib-2.0/{glib-2.0_2.88.0.bb => glib-2.0_2.88.2.bb} (100%)
diff --git a/meta/recipes-core/glib-2.0/files/CVE-2026-58016-1.patch b/meta/recipes-core/glib-2.0/files/CVE-2026-58016-1.patch
index 2c4b248b97..9beafd106d 100644
--- a/meta/recipes-core/glib-2.0/files/CVE-2026-58016-1.patch
+++ b/meta/recipes-core/glib-2.0/files/CVE-2026-58016-1.patch
@@ -30,7 +30,7 @@ diff --git a/gio/gdbusintrospection.c b/gio/gdbusintrospection.c
index c7be334ce2f7..6f722ee6153d 100644
--- a/gio/gdbusintrospection.c
+++ b/gio/gdbusintrospection.c
-@@ -1272,7 +1272,7 @@ parser_start_element (GMarkupParseContext *context,
+@@ -1258,7 +1258,7 @@ parser_start_element (GMarkupParseContext *context,
/* ---------------------------------------------------------------------------------------------------- */
if (strcmp (element_name, "node") == 0)
{
@@ -43,10 +43,10 @@ diff --git a/gio/tests/gdbus-introspection.c b/gio/tests/gdbus-introspection.c
index 44cb7a96af45..daca313f77e7 100644
--- a/gio/tests/gdbus-introspection.c
+++ b/gio/tests/gdbus-introspection.c
-@@ -299,6 +299,38 @@ test_extra_data (void)
+@@ -300,6 +300,38 @@ test_extra_data (void)
g_dbus_node_info_unref (info);
}
-
+
+static void
+test_invalid (void)
+{
@@ -80,14 +80,14 @@ index 44cb7a96af45..daca313f77e7 100644
+}
+
/* ---------------------------------------------------------------------------------------------------- */
-
+
int
-@@ -316,6 +348,7 @@ main (int argc,
+@@ -317,6 +349,7 @@ main (int argc,
g_test_add_func ("/gdbus/introspection-generate", test_generate);
g_test_add_func ("/gdbus/introspection-default-direction", test_default_direction);
g_test_add_func ("/gdbus/introspection-extra-data", test_extra_data);
+ g_test_add_func ("/gdbus/introspection/invalid", test_invalid);
-
+
ret = session_bus_run ();
--
diff --git a/meta/recipes-core/glib-2.0/files/CVE-2026-58016-2.patch b/meta/recipes-core/glib-2.0/files/CVE-2026-58016-2.patch
index a61e35ad8a..a07aa529ae 100644
--- a/meta/recipes-core/glib-2.0/files/CVE-2026-58016-2.patch
+++ b/meta/recipes-core/glib-2.0/files/CVE-2026-58016-2.patch
@@ -30,63 +30,63 @@ diff --git a/gio/gdbusintrospection.c b/gio/gdbusintrospection.c
index 6f722ee6153d..ed0d291f99f0 100644
--- a/gio/gdbusintrospection.c
+++ b/gio/gdbusintrospection.c
-@@ -1110,6 +1110,7 @@ parse_data_get_annotation (ParseData *data,
+@@ -1096,6 +1096,7 @@ parse_data_get_annotation (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->annotations, g_new0 (GDBusAnnotationInfo, 1));
+ g_assert (data->annotations->len > 0);
return data->annotations->pdata[data->annotations->len - 1];
}
-
-@@ -1119,6 +1120,7 @@ parse_data_get_arg (ParseData *data,
+
+@@ -1105,6 +1106,7 @@ parse_data_get_arg (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->args, g_new0 (GDBusArgInfo, 1));
+ g_assert (data->args->len > 0);
return data->args->pdata[data->args->len - 1];
}
-
-@@ -1128,6 +1130,7 @@ parse_data_get_out_arg (ParseData *data,
+
+@@ -1114,6 +1116,7 @@ parse_data_get_out_arg (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->out_args, g_new0 (GDBusArgInfo, 1));
+ g_assert (data->out_args->len > 0);
return data->out_args->pdata[data->out_args->len - 1];
}
-
-@@ -1137,6 +1140,7 @@ parse_data_get_method (ParseData *data,
+
+@@ -1123,6 +1126,7 @@ parse_data_get_method (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->methods, g_new0 (GDBusMethodInfo, 1));
+ g_assert (data->methods->len > 0);
return data->methods->pdata[data->methods->len - 1];
}
-
-@@ -1146,6 +1150,7 @@ parse_data_get_signal (ParseData *data,
+
+@@ -1132,6 +1136,7 @@ parse_data_get_signal (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->signals, g_new0 (GDBusSignalInfo, 1));
+ g_assert (data->signals->len > 0);
return data->signals->pdata[data->signals->len - 1];
}
-
-@@ -1155,6 +1160,7 @@ parse_data_get_property (ParseData *data,
+
+@@ -1141,6 +1146,7 @@ parse_data_get_property (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->properties, g_new0 (GDBusPropertyInfo, 1));
+ g_assert (data->properties->len > 0);
return data->properties->pdata[data->properties->len - 1];
}
-
-@@ -1164,6 +1170,7 @@ parse_data_get_interface (ParseData *data,
+
+@@ -1150,6 +1156,7 @@ parse_data_get_interface (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->interfaces, g_new0 (GDBusInterfaceInfo, 1));
+ g_assert (data->interfaces->len > 0);
return data->interfaces->pdata[data->interfaces->len - 1];
}
-
-@@ -1173,6 +1180,7 @@ parse_data_get_node (ParseData *data,
+
+@@ -1159,6 +1166,7 @@ parse_data_get_node (ParseData *data,
{
if (create_new)
g_ptr_array_add (data->nodes, g_new0 (GDBusNodeInfo, 1));
diff --git a/meta/recipes-core/glib-2.0/glib-2.0-initial_2.88.0.bb b/meta/recipes-core/glib-2.0/glib-2.0-initial_2.88.2.bb
similarity index 100%
rename from meta/recipes-core/glib-2.0/glib-2.0-initial_2.88.0.bb
rename to meta/recipes-core/glib-2.0/glib-2.0-initial_2.88.2.bb
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.88.0.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.88.2.bb
similarity index 100%
rename from meta/recipes-core/glib-2.0/glib-2.0_2.88.0.bb
rename to meta/recipes-core/glib-2.0/glib-2.0_2.88.2.bb
diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index fb35f84eec..d49ae13168 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -240,7 +240,7 @@ SRC_URI:append:class-native = " file://relocate-modules.patch \
file://0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch \
"
-SRC_URI[archive.sha256sum] = "3546251ccbb3744d4bc4eb48354540e1f6200846572bab68e3a2b7b2b64dfd07"
+SRC_URI[archive.sha256sum] = "cf3f215a640c8a4257f14317586b8f1fdd25a10a93cb4bdda147c0f9ad88e74f"
# Find any meson cross files in FILESPATH that are relevant for the current
# build (using siteinfo) and add them to EXTRA_OEMESON.
^ permalink raw reply related
* Re: [OE-core] [scarthgap][PATCH] extrausers: Terminate set_user_group post-process command
From: Yoann Congal @ 2026-07-19 22:15 UTC (permalink / raw)
To: chalianis1, openembedded-core; +Cc: Anis Chali
In-Reply-To: <20260713152937.200292-1-chalianis1@gmail.com>
On Mon Jul 13, 2026 at 5:29 PM CEST, chalianis1 via lists.openembedded.org wrote:
> From: Anis Chali <anis.chali@ro-main.com>
>
> Add the missing command separator to prevent the command from being
> concatenated with subsequent ROOTFS_POSTPROCESS_COMMAND entries.
>
> Signed-off-by: Anis Chali <chalianis1@gmail.com>
> ---
> meta/classes/extrausers.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/extrausers.bbclass b/meta/classes/extrausers.bbclass
> index c825c06df9..94576b8872 100644
> --- a/meta/classes/extrausers.bbclass
> +++ b/meta/classes/extrausers.bbclass
> @@ -23,7 +23,7 @@ inherit useradd_base
> PACKAGE_INSTALL:append = " ${@['', 'base-passwd shadow'][bool(d.getVar('EXTRA_USERS_PARAMS'))]}"
>
> # Image level user / group settings
> -ROOTFS_POSTPROCESS_COMMAND:append = " set_user_group"
> +ROOTFS_POSTPROCESS_COMMAND:append = " set_user_group;"
>
> # Image level user / group settings
> set_user_group () {
Hello,
ROOTFS_POSTPROCESS_COMMAND is not a shell command delimited by ';' but a
space separated list of bitbake recipes functions. So the
ROOTFS_POSTPROCESS_COMMAND:append = " ..." is correct here. If you have
concatenation problem, they are likely caused by the next function not
ensuring the space separation.
Also, FYI, we have a master-first policy, to accept this patch, similar
patches would have been sent to master and wrynose.
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [PATCH v3][scarthgap] python3: fix CVE-2026-7210
From: Yoann Congal @ 2026-07-19 21:48 UTC (permalink / raw)
To: amaury.couderc, openembedded-core
In-Reply-To: <20260706132712.51931-1-amaury.couderc@est.tech>
Hello,
On Mon Jul 6, 2026 at 3:26 PM CEST, Amaury Couderc via lists.openembedded.org wrote:
> From: Amaury Couderc <amaury.couderc@est.tech>
>
> CVE-2026-7210 is a hash-flooding denial-of-service vulnerability in
> Python's XML parsing modules (xml.parsers.expat, xml.etree.ElementTree).
> An attacker can craft XML input that forces O(n²) hash collisions in
> libexpat's internal name dictionary, causing excessive CPU consumption.
>
> The previous mitigation seeded libexpat's hash function with only 4
> bytes of entropy, which is insufficient against a determined attacker.
> This patch upgrades to XML_SetHashSalt16Bytes (libexpat >= 2.8.0),
> providing a full 16-byte secret. Older expat versions fall back
> gracefully to the legacy XML_SetHashSalt via a runtime NULL check.
>
> Backport patch to fix CVE-2026-7210.
> https://nvd.nist.gov/vuln/detail/CVE-2026-7210
>
> Upstream fix:
> https://github.com/python/cpython/commit/24b8f12544468e4cedf5bfbe25442fcd495391e4
>
> Tested with ptest:
> Before: PASSED: 40019, FAILED: 0, SKIPPED: 1882
> After: PASSED: 40020, FAILED: 0, SKIPPED: 1882
>
> CVE: CVE-2026-7210
>
> Signed-off-by: Amaury Couderc <amaury.couderc@est.tech>
> ---
>
> NOTE: CVE-2026-7210 full mitigation requires the companion
> expat CVE-2026-41080 patch (raises expat to >= 2.8.0 API)
>
> .../python/python3/CVE-2026-7210.patch | 122 ++++++++++++++++++
> .../python/python3_3.12.13.bb | 1 +
> 2 files changed, 123 insertions(+)
> create mode 100644 meta/recipes-devtools/python/python3/CVE-2026-7210.patch
>
> diff --git a/meta/recipes-devtools/python/python3/CVE-2026-7210.patch b/meta/recipes-devtools/python/python3/CVE-2026-7210.patch
> new file mode 100644
> index 0000000000..8acf174a0a
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3/CVE-2026-7210.patch
> @@ -0,0 +1,122 @@
> +From 2ed6138dea0bc94c726f879501e4525712e885d1 Mon Sep 17 00:00:00 2001
> +From: Stan Ulbrych <stan@python.org>
> +Date: Sun, 10 May 2026 18:36:26 +0100
> +Subject: [PATCH] gh-149018: Use `XML_SetHashSalt16Bytes` in
> + `pyexpat`/`_elementtree` when possible (#149023)
> +
> +
> +CVE: CVE-2026-7210
> +Upstream-Status: Backport [https://github.com/python/cpython/commit/24b8f12544468e4cedf5bfbe25442fcd495391e4]
> +
> +Signed-off-by: Amaury Couderc <amaury.couderc@est.tech>
> +---
> + Include/pyexpat.h | 3 +++
> + Include/pyhash.h | 8 +++++---
> + .../2026-04-26-19-30-45.gh-issue-149018.a9SqWb.rst | 3 +++
> + Modules/_elementtree.c | 8 ++++++--
> + Modules/pyexpat.c | 10 +++++++++-
> + 5 files changed, 26 insertions(+), 6 deletions(-)
> + create mode 100644 Misc/NEWS.d/next/Security/2026-04-26-19-30-45.gh-issue-149018.a9SqWb.rst
The patched files have slighty changed
Include/internal/pycore_pyhash.h -> Include/pyhash.h
This time, I could check that nothing important changed but next time
I'd like a like a little change log about what changed between upstream
and the imported patch.
> [...]
> +diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c
> +index 79492ca5c4f..388473d3855 100644
> +--- a/Modules/pyexpat.c
> ++++ b/Modules/pyexpat.c
> +@@ -1388,7 +1388,10 @@ newxmlparseobject(pyexpat_state *state, const char *encoding,
> + Py_DECREF(self);
> + return NULL;
> + }
> +-#if XML_COMBINED_VERSION >= 20100
> ++#if XML_COMBINED_VERSION >= 20800
> ++ /* This feature was added upstream in libexpat 2.8.0. */
> ++ XML_SetHashSalt16Bytes(self->itself, _Py_HashSecret.expat.hashsalt16);
> ++#elif XML_COMBINED_VERSION >= 20100
> + /* This feature was added upstream in libexpat 2.1.0. */
> + XML_SetHashSalt(self->itself,
> + (unsigned long)_Py_HashSecret.expat.hashsalt);
> +@@ -2257,6 +2260,11 @@ pyexpat_exec(PyObject *mod)
> + #else
> + capi->SetHashSalt = NULL;
> + #endif
> ++#if XML_COMBINED_VERSION >= 20800
> ++ capi->SetHashSalt16Bytes = XML_SetHashSalt16Bytes;
> ++#else
> ++ capi->SetHashSalt16Bytes = NULL;
> ++#endif
> + #if XML_COMBINED_VERSION >= 20600
> + capi->SetReparseDeferralEnabled = XML_SetReparseDeferralEnabled;
> + #else
We did not upgrade expat but patched in the fixing API
XML_SetHashSalt16Bytes. Can you check we can activate the fixed code
path with those "#if XML_COMBINED_VERSION >= 20800"?
I will hold the patch in the meantime, I really want to avoid a false
negative in CVE data.
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [PATCH v4 01/27] bitbake: globally define KERNEL_PACKAGE_NAME
From: Richard Purdie @ 2026-07-19 21:25 UTC (permalink / raw)
To: vince, openembedded-core
In-Reply-To: <953617.1784488771319074426@lists.openembedded.org>
On Sun, 2026-07-19 at 12:19 -0700, Vincent Davis Jr via
lists.openembedded.org wrote:
> Any feedback besides
>
> Bruce and Peter comments.
>
> Before I submit v5 to address review comments.
We discussed this briefly in the patch review call last week and I
think we were all a bit concerned about the patch series.
There was some work some time ago to try and make multiple kernels
build in parallel and parameterise some of the code. This does seem to
be a continuation of that work.
What some of us were wondering is whether the kernel-XXX prefix was
intended to be the general "default" namespace which each kernel/module
would provide, then the provider could be switched without the need to
have all parameterisation this series ends up implementing.
Unfortunately I've not had a chance to think about that more deeply and
work out if that can be done or we really do have to change all the
references as this series does.
Cheers,
Richard
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH 3/3] python3: fix CVE-2026-9669
From: Yoann Congal @ 2026-07-19 21:22 UTC (permalink / raw)
To: benjamin.robin, openembedded-core
Cc: olivier.benjamin, mathieu.dubois-briand, pascal.eberhard,
wahid.essid
In-Reply-To: <20260706-fix-cves-python-scarthgap-v1-3-8d51db14f7ac@bootlin.com>
Hello,
On Mon Jul 6, 2026 at 1:01 PM CEST, Benjamin Robin via lists.openembedded.org wrote:
> bz2.BZ2Decompressor objects could be reused after a decompression error.
> If an application caught the resulting OSError and retried with the same
> decompressor, crafted input could cause the decompressor to resume from an
> invalid internal state and perform out-of-bounds writes to a stack buffer.
> This could crash the process when processing untrusted data.
>
> Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
More than a description of the vulnerability, what we need in the commit
message is a justification for the patch: i.e. why this is the patch we
should take to fix this CVE? In this case, this is trivial, this is a
patch referenced from the NVD page. But better state it.
> ---
> .../python/python3/CVE-2026-9669.patch | 97 ++++++++++++++++++++++
> meta/recipes-devtools/python/python3_3.12.13.bb | 1 +
> 2 files changed, 98 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python3/CVE-2026-9669.patch b/meta/recipes-devtools/python/python3/CVE-2026-9669.patch
> new file mode 100644
> index 000000000000..933d6f410ee1
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3/CVE-2026-9669.patch
> @@ -0,0 +1,97 @@
> +From 5b412e1f7bdb3e0667b2bc8b216ad216d59d8373 Mon Sep 17 00:00:00 2001
> +From: "Miss Islington (bot)"
> + <31488909+miss-islington@users.noreply.github.com>
> +Date: Mon, 8 Jun 2026 11:55:32 +0200
> +Subject: [PATCH] gh-150599: Prevent bz2 decompressor reuse after errors
> + (GH-150600)
> +
> +CVE: CVE-2026-9669
> +Upstream-Status: Backport [https://github.com/python/cpython/commit/5755d0f083949ff3c5bf3a37e673e24e306b036e]
> +
> +Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
The upstream patch has author="Stan Ulbrych <stan@python.org>".
Please send a v2 with those 2 points fixed.
Thanks!
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH 2/3] python3: fix CVE-2026-11972
From: Yoann Congal @ 2026-07-19 21:08 UTC (permalink / raw)
To: benjamin.robin, openembedded-core
Cc: olivier.benjamin, mathieu.dubois-briand, pascal.eberhard,
wahid.essid
In-Reply-To: <20260706-fix-cves-python-scarthgap-v1-2-8d51db14f7ac@bootlin.com>
On Mon Jul 6, 2026 at 1:01 PM CEST, Benjamin Robin via lists.openembedded.org wrote:
> When using the "tarfile" module with a file opened in "streaming mode"
> (mode="r|") the tarfile module did not properly handle EOF, making archive
> parsing take exponentially longer.
>
> Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
> ---
> .../python/python3/CVE-2026-11972.patch | 58 ++++++++++++++++++++++
> meta/recipes-devtools/python/python3_3.12.13.bb | 1 +
> 2 files changed, 59 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python3/CVE-2026-11972.patch b/meta/recipes-devtools/python/python3/CVE-2026-11972.patch
> new file mode 100644
> index 000000000000..0752ba372dcc
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3/CVE-2026-11972.patch
> @@ -0,0 +1,58 @@
> +From a83ebdb495a9cbd28a03675acdeda235fade90b3 Mon Sep 17 00:00:00 2001
> +From: Petr Viktorin <encukou@gmail.com>
> +Date: Tue, 23 Jun 2026 15:13:30 +0200
> +Subject: [PATCH] gh-151981: Make tarfile._Stream.seek break at EOF (GH-151982)
> +
> +CVE: CVE-2026-11972
> +Upstream-Status: Backport [https://github.com/python/cpython/commit/f50bf13566189c8d0ce5a814f33eff3d89951896]
> +
> +Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
Hello,
Like we discussed for wrynose, this patch lacks the co-authored-by it
has upstream. Can you send a v2 with this fixed?
Thanks!
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] binutils: fix CVE-2025-69645
From: Yoann Congal @ 2026-07-19 20:43 UTC (permalink / raw)
To: roland.kovacs, openembedded-core
In-Reply-To: <20260716095854.65840-1-roland.kovacs@est.tech>
Hello,
On Thu Jul 16, 2026 at 11:58 AM CEST, Roland Kovács via lists.openembedded.org wrote:
> Binutils objdump contains a denial-of-service vulnerability when processing
> a crafted binary with malformed DWARF debug information. A logic error in
> the handling of DWARF compilation units can result in an invalid offset_size
> value being used inside byte_get_little_endian, leading to an abort (SIGABRT).
> A local attacker can trigger the crash by supplying a malicious input file.
>
> Signed-off-by: Roland Kovacs <roland.kovacs@est.tech>
> ---
> .../binutils/binutils-2.42.inc | 1 +
> .../binutils/binutils/CVE-2025-69645.patch | 135 ++++++++++++++++++
> 2 files changed, 136 insertions(+)
> create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2025-69645.patch
More than a description of the vulnerability, what we need in the commit
message is a justification for the patch: i.e. why this is the patch we
should take to fix this CVE? In this case, this is trivial, this is the
patch referenced from the NVD page, so I've added it.
Also, the NVD entry looks wrong: only the 2.44 version is said impacted
but the patches to fix apply way more than that. Can you reach them and
fix the NVD data?
Thanks!
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [PATCH 2/2] kernel-fit-image: introduce FIT_OS variable to override 'os' field
From: adrian.freihofer @ 2026-07-19 19:37 UTC (permalink / raw)
To: nora.schiffer, openembedded-core; +Cc: oss
In-Reply-To: <30d89efad3d693785555868ea8c7f1c7b7b5cf46.1783422721.git.nora.schiffer@ew.tq-group.com>
On Tue, 2026-07-07 at 13:29 +0200, Nora Schiffer via
lists.openembedded.org wrote:
> U-Boot can load an EFI application from a FIT image; this requires
> setting the OS to "efi" (usually in combination with type
> "kernel_noload"). Doing so is a convenient approach for giving the OS
> access to EFI services while preserving other benefits of FIT image
> boot.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> meta/classes-recipe/kernel-fit-image.bbclass | 3 ++-
> meta/conf/image-fitimage.conf | 4 ++++
> meta/lib/oe/fitimage.py | 11 ++++++-----
> meta/lib/oeqa/selftest/cases/fitimage.py | 13 +++++++++++--
> 4 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel-fit-image.bbclass
> b/meta/classes-recipe/kernel-fit-image.bbclass
> index 448a88ccb1..899516e372 100644
> --- a/meta/classes-recipe/kernel-fit-image.bbclass
> +++ b/meta/classes-recipe/kernel-fit-image.bbclass
> @@ -69,7 +69,8 @@ python do_compile() {
> # Collect all the its nodes before the its file is generated and
> mkimage gets executed
> root_node = oe.fitimage.ItsNodeRootKernel(
> d.getVar("FIT_DESC"), d.getVar("FIT_ADDRESS_CELLS"),
> - d.getVar('HOST_PREFIX'), d.getVar('UBOOT_ARCH'),
> d.getVar("FIT_CONF_PREFIX"),
> + d.getVar('HOST_PREFIX'), d.getVar('UBOOT_ARCH'),
> d.getVar('FIT_OS'),
> + d.getVar("FIT_CONF_PREFIX"),
> oe.types.boolean(d.getVar('FIT_KERNEL_SIGN_ENABLE')),
> d.getVar("FIT_KERNEL_SIGN_KEYDIR"),
> d.getVar("UBOOT_MKIMAGE"),
> d.getVar("UBOOT_MKIMAGE_DTCOPTS"),
> d.getVar('FIT_MKIMAGE_EXTRA_OPTS'),
> diff --git a/meta/conf/image-fitimage.conf b/meta/conf/image-
> fitimage.conf
> index 2fdb816d55..a06d30e494 100644
> --- a/meta/conf/image-fitimage.conf
> +++ b/meta/conf/image-fitimage.conf
> @@ -37,6 +37,10 @@ FIT_CONF_PREFIX[doc] = "Prefix to use for FIT
> configuration node name"
>
> FIT_SUPPORTED_INITRAMFS_FSTYPES ?= "cpio.lz4 cpio.lzo cpio.lzma
> cpio.xz cpio.zst cpio.gz ext2.gz cpio"
>
> +# os field of the kernel and various other images in the FIT image.
> Set to "efi"
> +# to load a kernel with EFI stub as an EFI application.
> +FIT_OS ?= "linux"
> +
> # Allow user to support special use cases where the kernel binary is
> # not included in the FIT image itself.
> # This is particularly useful for UKI-based setups, where the kernel
> diff --git a/meta/lib/oe/fitimage.py b/meta/lib/oe/fitimage.py
> index 81d18f6c91..86a0e44e12 100644
> --- a/meta/lib/oe/fitimage.py
> +++ b/meta/lib/oe/fitimage.py
> @@ -153,7 +153,7 @@ class ItsNodeRootKernel(ItsNode):
> If a device tree included in the FIT image, the default
> configuration is the
> firt DTB. If there is no dtb present than the default
> configuation the kernel.
> """
> - def __init__(self, description, address_cells, host_prefix,
> arch, conf_prefix,
> + def __init__(self, description, address_cells, host_prefix,
> arch, os, conf_prefix,
Should we use "os" as a variable name? What happens if
import os
os = "efi" ?
os.path.join(...)
To be on the save side, I would suggest to use fit_os, for example.
Thank you for the patch. I think this needs a v2 because of this
detail. But otherwise it looks good to me.
Sorry for the late response,
Adrian
> sign_enable=False, sign_keydir=None,
> mkimage=None, mkimage_dtcopts=None,
> mkimage_extra_opts=None,
> @@ -171,6 +171,7 @@ class ItsNodeRootKernel(ItsNode):
>
> self._host_prefix = host_prefix
> self._arch = arch
> + self._os = os
> self._conf_prefix = conf_prefix
>
> # Signature related properties
> @@ -279,7 +280,7 @@ class ItsNodeRootKernel(ItsNode):
> opt_props = {
> "data": '/incbin/("' + kernel_path + '")',
> "arch": self._arch,
> - "os": "linux",
> + "os": self._os,
> }
> if load:
> opt_props["load"] = f"<{load}>"
> @@ -370,7 +371,7 @@ class ItsNodeRootKernel(ItsNode):
> {
> "data": '/incbin/("' + setup_path + '")',
> "arch": self._arch,
> - "os": "linux",
> + "os": self._os,
> "load": load,
> "entry": entry
> }
> @@ -385,7 +386,7 @@ class ItsNodeRootKernel(ItsNode):
> "data": '/incbin/("' + ramdisk_path + '")',
> "type": "ramdisk",
> "arch": self._arch,
> - "os": "linux"
> + "os": self._os,
> }
> if load:
> opt_props["load"] = f"<{load}>"
> @@ -406,7 +407,7 @@ class ItsNodeRootKernel(ItsNode):
> opt_props = {
> "data": '/incbin/("' + filepath + '")',
> "arch": arch if arch is not None else self._arch,
> - "os": os if os is not None else "linux",
> + "os": os if os is not None else self._os,
> }
>
> if load:
> diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
> b/meta/lib/oeqa/selftest/cases/fitimage.py
> index c5f2975223..d28b5b8965 100644
> --- a/meta/lib/oeqa/selftest/cases/fitimage.py
> +++ b/meta/lib/oeqa/selftest/cases/fitimage.py
> @@ -670,6 +670,7 @@ class KernelFitImageBase(FitImageTestCase):
> 'FIT_LOADABLES',
> 'FIT_LOADABLE_ENTRYPOINT',
> 'FIT_LOADABLE_LOADADDRESS',
> + 'FIT_OS',
> 'FIT_SIGN_ALG',
> 'FIT_SIGN_INDIVIDUAL',
> 'FIT_UBOOT_ENV',
> @@ -904,7 +905,7 @@ class KernelFitImageBase(FitImageTestCase):
> # 'compression = "' +
> str(bb_vars['FIT_KERNEL_COMP_ALG']) + '";', defined based on files in
> TMPDIR, not ideal...
> 'data = /incbin/("linux.bin");',
> 'arch = "' + str(bb_vars['UBOOT_ARCH']) + '";',
> - 'os = "linux";',
> + 'os = "%s";' % bb_vars['FIT_OS'],
> 'load = <' + str(bb_vars['UBOOT_LOADADDRESS']) + '>;',
> 'entry = <' + str(bb_vars['UBOOT_ENTRYPOINT']) + '>;',
> ]
> @@ -1463,6 +1464,7 @@ class FitImagePyTests(KernelFitImageBase):
> 'FIT_KEY_SIGN_PKCS': "-x509",
> 'FIT_LOADABLES': "",
> 'FIT_LINUX_BIN': "linux.bin",
> + 'FIT_OS': "linux",
> 'FIT_PAD_ALG': "pkcs-1.5",
> 'FIT_SIGN_ALG': "rsa2048",
> 'FIT_SIGN_INDIVIDUAL': "0",
> @@ -1503,7 +1505,8 @@ class FitImagePyTests(KernelFitImageBase):
>
> root_node = oe.fitimage.ItsNodeRootKernel(
> bb_vars["FIT_DESC"], bb_vars["FIT_ADDRESS_CELLS"],
> - bb_vars['HOST_PREFIX'], bb_vars['UBOOT_ARCH'],
> bb_vars["FIT_CONF_PREFIX"],
> + bb_vars['HOST_PREFIX'], bb_vars['UBOOT_ARCH'],
> bb_vars['FIT_OS'],
> + bb_vars["FIT_CONF_PREFIX"],
> oe.types.boolean(bb_vars['UBOOT_SIGN_ENABLE']),
> bb_vars["UBOOT_SIGN_KEYDIR"],
> bb_vars["UBOOT_MKIMAGE"],
> bb_vars["UBOOT_MKIMAGE_DTCOPTS"],
> bb_vars["UBOOT_MKIMAGE_SIGN"],
> bb_vars["UBOOT_MKIMAGE_SIGN_ARGS"],
> @@ -1609,6 +1612,12 @@ class FitImagePyTests(KernelFitImageBase):
> }
> self._test_fitimage_py(bb_vars_overrides)
>
> + def test_fitimage_py_conf_os(self):
> + """Test FIT_OS functionality"""
> + bb_vars_overrides = {
> + 'FIT_OS': "efi",
> + }
> + self._test_fitimage_py(bb_vars_overrides)
>
> class UBootFitImageTests(FitImageTestCase):
> """Test cases for the uboot-sign bbclass"""
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#240383):
> https://lists.openembedded.org/g/openembedded-core/message/240383
> Mute This Topic: https://lists.openembedded.org/mt/120154469/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: [PATCH v4 01/27] bitbake: globally define KERNEL_PACKAGE_NAME
From: Vincent Davis Jr @ 2026-07-19 19:19 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <DB5PR02MB102131BF9EDB1F84965702DABEFFA2@DB5PR02MB10213.eurprd02.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Any feedback besides
Bruce and Peter comments.
Before I submit v5 to address review comments.
[-- Attachment #2: Type: text/html, Size: 148 bytes --]
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] glibc-testsuite: inherit nospdx to fix do_create_spdx failure
From: Yoann Congal @ 2026-07-19 17:26 UTC (permalink / raw)
To: jaipaul.cheernam, openembedded-core
In-Reply-To: <20260708115052.71740-1-jaipaul.cheernam@est.tech>
On Wed Jul 8, 2026 at 1:50 PM CEST, Jaipaul Cheernam via lists.openembedded.org wrote:
> The glibc-testsuite recipe fails during do_create_spdx with:
>
> ERROR: glibc-testsuite-2.39+git-r1 do_create_spdx: Recipe glibc-testsuite
> is trying to create package sln which was already written by recipe glibc.
> This will cause corruption, please resolve this and only provide the
> package from one recipe or the other or only build one of the recipes.
>
> This happens because glibc-testsuite includes glibc_2.39.bb via 'require'
> to reuse its source and build configuration for running 'make check'. As a
> result, it inherits all of glibc's PACKAGES definitions (including sln).
> While the recipe already inherits 'nopackages' to suppress packaging, the
> nopackages class does not disable SPDX tasks. The do_create_spdx task then
> attempts to generate SPDX data for packages like 'sln', conflicting with
> the real glibc recipe that owns that package.
>
> This issue was exposed by the SPDX 3.0 backport (commit 9c9b954504,
> Nov 2025) which introduced stricter package-level SPDX generation.
>
> Fix this by adding 'inherit nospdx'. glibc-testsuite does not run on
> target or factor into the build supply chain, since its purpose is to
> run tests in QEMU at build time.
>
> (cherry picked from commit 32801348ca231978498612f3ebee121ca27459c1)
Hello,
That is not a straight forward cherry-pick. Commit message and author
where rewritten.
If you need to add backport info to the cherry-pick, add them after the
"(cherry picked from ..." line but keep the rest (author, title, body)
the same.
You can either send me a v2 with proper cherry-pick procedure (only
append, no rewrite) or just request a cherry-pick for me to handle
(looks easy enough).
Regards,
> Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
> ---
> meta/recipes-core/glibc/glibc-testsuite_2.39.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.39.bb b/meta/recipes-core/glibc/glibc-testsuite_2.39.bb
> index 2e076f4b0f..e0e3e8ba84 100644
> --- a/meta/recipes-core/glibc/glibc-testsuite_2.39.bb
> +++ b/meta/recipes-core/glibc/glibc-testsuite_2.39.bb
> @@ -31,6 +31,7 @@ do_check:append () {
> }
>
> inherit nopackages
> +inherit nospdx
> deltask do_stash_locale
> deltask do_install
> deltask do_populate_sysroot
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] create-spdx-image-3.0: correct SSTATE_SKIP_CREATION key for do_create_image_sbom_spdx
From: Yoann Congal @ 2026-07-19 17:14 UTC (permalink / raw)
To: benjamin.robin, openembedded-core
Cc: olivier.benjamin, thomas.petazzoni, mathieu.dubois-briand,
pascal.eberhard, wahid.essid, Eric Meyers, Joshua Watt,
Richard Purdie, Eric Meyers
In-Reply-To: <20260708-fix-sstate-create-spdx-image-scarthgap-v1-1-8f605c913801@bootlin.com>
On Wed Jul 8, 2026 at 9:11 AM CEST, Benjamin Robin via lists.openembedded.org wrote:
> From: Eric Meyers <eric.meyers15310@gmail.com>
>
> The override was "task-create-image-sbom" but BitBake derives it as
> "task-create-image-sbom-spdx" (do_ stripped, underscores to hyphens), so
> the skip was never applied. The task then cached an ${IMAGE_NAME}-stamped
> SBOM in sstate, letting a stale spdx.json be restored via setscene. A
> later do_sbom_cve_check would compute the current IMAGE_NAME and fail with
> "No such file or directory" on the missing timestamped SBOM. Correct the
> key so the image SBOM is always regenerated, never restored from sstate.
>
> (cherry picked from commit 45302ff5cfaf91ece74d4065acf710507f27da15)
>
> Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
Beware, you removed the trailers (SoB: ...) while cherry-picking.
I restored them.
Regards,
> ---
> Backport this fix to scarthgap.
> ---
> meta/classes-recipe/create-spdx-image-3.0.bbclass | 2 +-
> meta/classes-recipe/nospdx.bbclass | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/create-spdx-image-3.0.bbclass b/meta/classes-recipe/create-spdx-image-3.0.bbclass
> index e0f1766bb766..c516e9545653 100644
> --- a/meta/classes-recipe/create-spdx-image-3.0.bbclass
> +++ b/meta/classes-recipe/create-spdx-image-3.0.bbclass
> @@ -71,7 +71,7 @@ python do_create_image_sbom_spdx() {
> }
> addtask do_create_image_sbom_spdx after do_create_rootfs_spdx do_create_image_spdx before do_build
> SSTATETASKS += "do_create_image_sbom_spdx"
> -SSTATE_SKIP_CREATION:task-create-image-sbom = "1"
> +SSTATE_SKIP_CREATION:task-create-image-sbom-spdx = "1"
> do_create_image_sbom_spdx[sstate-inputdirs] = "${SPDXIMAGEDEPLOYDIR}"
> do_create_image_sbom_spdx[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
> do_create_image_sbom_spdx[stamp-extra-info] = "${MACHINE_ARCH}"
> diff --git a/meta/classes-recipe/nospdx.bbclass b/meta/classes-recipe/nospdx.bbclass
> index b20e28218be9..913b213a6543 100644
> --- a/meta/classes-recipe/nospdx.bbclass
> +++ b/meta/classes-recipe/nospdx.bbclass
> @@ -10,4 +10,4 @@ deltask do_create_spdx_runtime
> deltask do_create_package_spdx
> deltask do_create_rootfs_spdx
> deltask do_create_image_spdx
> -deltask do_create_image_sbom
> +deltask do_create_image_sbom_spdx
>
> ---
> base-commit: 2814f0962f56c8d1afa4de76d2895ba9b5cb767d
> change-id: 20260708-fix-sstate-create-spdx-image-scarthgap-697f60f4ab87
>
> Best regards,
> --
> Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com>
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [PATCH v3 0/6] wic: ship its tools, and add an SDK_FEATURES lever
From: Mathieu Dubois-Briand @ 2026-07-19 15:48 UTC (permalink / raw)
To: twoerner, openembedded-core
In-Reply-To: <20260717133421.3510970-1-twoerner@gmail.com>
On Fri Jul 17, 2026 at 3:34 PM CEST, Trevor Woerner via lists.openembedded.org wrote:
> wic shells out to a range of host-side tools but does not declare them,
> so wherever it is installed as a package (rather than run from the
> bitbake do_image_wic task, which has the wic-tools native sysroot on
> PATH) it works only by chance depending on what the host has installed.
>
> Patch 1 fixes that directly: wic gains RDEPENDS on the tools it runs, so
> they are installed alongside it in every variant that packages it.
>
> The rest of the series turns "what optional tools go into the SDK" into
> an explicit, self-documenting choice. It introduces SDK_FEATURES, a list
> in the same spirit as DISTRO_FEATURES / MACHINE_FEATURES / IMAGE_FEATURES:
> a developer reads the setting and knows exactly what their SDK contains.
>
> - patch 2 adds SDK_FEATURES and gates wic on the "wic" feature (off by
> default);
> - patch 3 moves the existing (unconditional, arch-gated) qemu addition
> behind a "qemu" feature, on by default so nothing regresses;
> - patch 4 adds an opt-in "sbom" feature (SPDX + SBOM/CVE tooling);
> - patch 5 moves the cross-canadian gdb behind a "gdb" feature, on by
> default; binutils and gcc stay unconditional since a cross-compiler
> is intrinsic to an SDK;
> - patch 6 adds an opt-in "lldb" feature for developers who prefer it.
>
> The default SDK_FEATURES is "gdb qemu", so an unmodified configuration
> produces the same SDK as before. The intent is to present the full range
> of knobs and let review settle which belong on by default; the split
> across separate patches is deliberate so each can be debated on its own.
> SDK_FEATURES is a plain list, so downstream layers can define their own
> features (for example a cgdb feature in meta-openembedded) the same way.
>
Hi Trevor,
Thanks for the new version. It looks like we have 2 selftest fails:
2026-07-19 07:16:57,038 - oe-selftest - INFO - sstatetests.SStateHashSameSigs2.test_sstate_allarch_samesigs (subunit.RemotedTestCase)
2026-07-19 07:16:57,040 - oe-selftest - INFO - ... FAIL
...
ERROR: When reparsing /tmp/selftest-fetchvua2hn0x/test.bb:do_checkuri, the basehash value changed from eaf531c7d0304fd45f77fab173d0399db2b76e45cd46487426eb74bae7d4b7bb to 2cdec1b5839750d0c5998dd35b7ab7380727d2fa3a33aed864144428d3a78f7d. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake test -cdo_checkuri -Snone
ERROR: Then:
ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
ERROR: When reparsing /tmp/selftest-fetchvua2hn0x/test.bb:do_fetch, the basehash value changed from 72505ac7986134cca1a5bf96409e922ca39d8b70914218c968f9a8b3d508bc81 to b34ab448c19b41b81625a8e8ffa143940fa6c6a3c9db18ecec38e83ee0e3b7bb. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake test -cdo_fetch -Snone
ERROR: Then:
ERROR: $ bitbake test -cdo_fetch -Sprintdiff
...
2026-07-19 07:21:21,814 - oe-selftest - INFO - sstatetests.SStateHashSameSigs2.test_sstate_nativesdk_samesigs_multilib (subunit.RemotedTestCase)
2026-07-19 07:21:21,814 - oe-selftest - INFO - ... FAIL
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4320
https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/4376
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/4142
I also got this error that might be related:
ERROR: Nothing RPROVIDES 'grub' (but /srv/pokybuild/yocto-worker/check-layer/build/layers/openembedded-core/meta/recipes-support/wic/wic_0.3.1.bb RDEPENDS on or otherwise requires it)
grub was skipped: incompatible with host arm-oe-linux-gnueabi (not in COMPATIBLE_HOST)
NOTE: Runtime target 'grub' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['grub']
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'wic', 'grub']
https://autobuilder.yoctoproject.org/valkyrie/#/builders/27/builds/4231
Can you have a look at the issue?
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] expat: patch CVE-2026-50219
From: Yoann Congal @ 2026-07-19 15:43 UTC (permalink / raw)
To: Yoann Congal, tgaige.opensource, openembedded-core; +Cc: hsimeliere.opensource
In-Reply-To: <DJJ4C13UUF69.11ICUQHKB6WN3@smile.fr>
On Fri Jun 26, 2026 at 6:23 PM CEST, Yoann Congal wrote:
> On Fri Jun 5, 2026 at 10:32 AM CEST, Theo Gaige via lists.openembedded.org wrote:
>> From: "Theo Gaige (Schneider Electric)" <tgaige.opensource@witekio.com>
>>
>> Backport patches from [1]
>>
>> [1] https://github.com/libexpat/libexpat/pull/1246
>
> This patch is enormous for a CVE fix! It deserves more justification
> than this. For example, you could detail what patch is preparation, what
> patch is the proper fix...
Hello,
Gentle ping for the above
Regards,
>> Signed-off-by: Theo Gaige (Schneider Electric) <tgaige.opensource@witekio.com>
>> ---
>> .../expat/expat/CVE-2026-50219-01.patch | 59 +++++++
>> .../expat/expat/CVE-2026-50219-02.patch | 82 ++++++++++
>> .../expat/expat/CVE-2026-50219-03.patch | 90 +++++++++++
>> .../expat/expat/CVE-2026-50219-04.patch | 32 ++++
>> .../expat/expat/CVE-2026-50219-05.patch | 46 ++++++
>> .../expat/expat/CVE-2026-50219-06.patch | 152 ++++++++++++++++++
>> .../expat/expat/CVE-2026-50219-07.patch | 30 ++++
>> .../expat/expat/CVE-2026-50219-08.patch | 42 +++++
>> .../expat/expat/CVE-2026-50219-09.patch | 42 +++++
>> .../expat/expat/CVE-2026-50219-10.patch | 33 ++++
>> .../expat/expat/CVE-2026-50219-11.patch | 30 ++++
>> .../expat/expat/CVE-2026-50219-12.patch | 40 +++++
>> .../expat/expat/CVE-2026-50219-13.patch | 47 ++++++
>> .../expat/expat/CVE-2026-50219-14.patch | 72 +++++++++
>> .../expat/expat/CVE-2026-50219-15.patch | 80 +++++++++
>> .../expat/expat/CVE-2026-50219-16.patch | 44 +++++
>> .../expat/expat/CVE-2026-50219-17.patch | 62 +++++++
>> .../expat/expat/CVE-2026-50219-18.patch | 30 ++++
>> .../expat/expat/CVE-2026-50219-19.patch | 85 ++++++++++
>> .../expat/expat/CVE-2026-50219-20.patch | 60 +++++++
>> .../expat/expat/CVE-2026-50219-21.patch | 44 +++++
>> .../expat/expat/CVE-2026-50219-22.patch | 46 ++++++
>> .../expat/expat/CVE-2026-50219-23.patch | 34 ++++
>> .../expat/expat/CVE-2026-50219-24.patch | 31 ++++
>> .../expat/expat/CVE-2026-50219-25.patch | 33 ++++
>> .../expat/expat/CVE-2026-50219-26.patch | 31 ++++
>> .../expat/expat/CVE-2026-50219-27.patch | 29 ++++
>> .../expat/expat/CVE-2026-50219-28.patch | 29 ++++
>> .../expat/expat/CVE-2026-50219-29.patch | 29 ++++
>> .../expat/expat/CVE-2026-50219-30.patch | 29 ++++
>> .../expat/expat/CVE-2026-50219-31.patch | 29 ++++
>> .../expat/expat/CVE-2026-50219-32.patch | 97 +++++++++++
>> .../expat/expat/CVE-2026-50219-33.patch | 39 +++++
>> .../expat/expat/CVE-2026-50219-34.patch | 39 +++++
>> meta/recipes-core/expat/expat_2.6.4.bb | 34 ++++
>> 35 files changed, 1731 insertions(+)
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-01.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-02.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-03.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-04.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-05.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-06.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-07.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-08.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-09.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-10.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-11.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-12.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-13.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-14.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-15.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-16.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-17.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-18.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-19.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-20.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-21.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-22.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-23.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-24.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-25.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-26.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-27.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-28.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-29.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-30.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-31.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-32.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-33.patch
>> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-50219-34.patch
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [poky][scarthgap][PATCH 1/2] libarchive: Fix CVE-2026-5121
From: Yoann Congal @ 2026-07-19 15:42 UTC (permalink / raw)
To: jeremy.rosen, bindudaniel1996, openembedded-core; +Cc: Bhabu Bindu, Sana Kazi
In-Reply-To: <DJ5ET6KPB9Z6.3IBVM148858ON@smile.fr>
On Wed Jun 10, 2026 at 3:39 PM CEST, Jérémy Rosen via lists.openembedded.org wrote:
> Hello Bindu
>
> The hunk you removed from archive_read_support_format_iso9660.c is the
> actual CVE fix, so what is left is the test only... but that's kinda
> normal
>
> As you mentionned, the fix is already included in CVE-2026-4426.patch
>
> upstream fixed both CVE with the same code in two separate, parllel but identical
> commits then merged them. Thus complicating backports
>
> please rename CVE-2026-4426.patch to CVE-2026-442_CVE-2026-5121.patch
>
> and add the new CVE tag and related test there
>
>
> please respin and send a version where both CVE are fixed in the same
> file
>
>
> thanks a lot for looking into this
> Jeremy
Hello,
Gentle ping for the above
Regards,
>
> On Fri May 22, 2026 at 12:18 PM CEST, BINDU via lists.openembedded.org wrote:
>> Fixes CVE-2026-5121, adds regression test for
>> zisofs 32-bit heap overflow
>>
>> Signed-off-by: Sana Kazi <Sana.Kazi@bmwtechworks.in>
>> ---
>> .../libarchive/libarchive/CVE-2026-5121.patch | 1271 +++++++++++++++++
>> .../libarchive/libarchive_3.7.9.bb | 1 +
>> 2 files changed, 1272 insertions(+)
>> create mode 100644 meta/recipes-extended/libarchive/libarchive/CVE-2026-5121.patch
>>
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core][scarthgap][PATCH] systemd: Fix CVE-2026-29111
From: Yoann Congal @ 2026-07-19 15:31 UTC (permalink / raw)
To: jeremy.rosen, hsimeliere.opensource, openembedded-core; +Cc: Bruno VERNAY
In-Reply-To: <DJ59MG1GNWTJ.3GZAL2LXOBJ70@smile.fr>
On Wed Jun 10, 2026 at 11:35 AM CEST, Jérémy Rosen via lists.openembedded.org wrote:
> hello Hugo
>
> when reviewing this patch, I found a couple of minor difference with the
> upstream patches
>
> [...]
>
>
> I suppose that these are due to backporting to older version of systemd
> but could you confirm ?
>
> please send a V2 with the explanation attached to the patch and ping us
> here
>
> Thanks a lot
Hello,
Gentle ping for the above
Regards,
>
>
> Jérémy
>
>
> On Wed May 20, 2026 at 11:59 AM CEST, Hugo Simeliere via lists.openembedded.org wrote:
>> From: "Hugo SIMELIERE (Schneider Electric)" <hsimeliere.opensource@witekio.com>
>>
>> Pick patches from [1], [2], [3] and [4] as mentioned in Debian report in [5].
>>
>> [1] https://github.com/systemd/systemd/commit/20021e7686426052e3a7505425d7e12085feb2a6
>> [2] https://github.com/systemd/systemd/commit/7ac3220213690e8a8d6d2a6e81e43bd1dce01d69
>> [3] https://github.com/systemd/systemd/commit/21167006574d6b83813c7596759b474f56562412
>> [4] https://github.com/systemd/systemd/commit/54588d2dedff54bfb6036670820650e4ea74628f
>> [5] https://security-tracker.debian.org/tracker/CVE-2026-29111
>>
>> Signed-off-by: Hugo SIMELIERE (Schneider Electric) <hsimeliere.opensource@witekio.com>
>> Reviewed-by: Bruno VERNAY <bruno.vernay@se.com>
>> ---
>> .../systemd/systemd/CVE-2026-29111-01.patch | 168 ++++++++++++++++++
>> .../systemd/systemd/CVE-2026-29111-02.patch | 87 +++++++++
>> .../systemd/systemd/CVE-2026-29111-03.patch | 103 +++++++++++
>> .../systemd/systemd/CVE-2026-29111-04.patch | 37 ++++
>> meta/recipes-core/systemd/systemd_255.21.bb | 4 +
>> 5 files changed, 399 insertions(+)
>> create mode 100644 meta/recipes-core/systemd/systemd/CVE-2026-29111-01.patch
>> create mode 100644 meta/recipes-core/systemd/systemd/CVE-2026-29111-02.patch
>> create mode 100644 meta/recipes-core/systemd/systemd/CVE-2026-29111-03.patch
>> create mode 100644 meta/recipes-core/systemd/systemd/CVE-2026-29111-04.patch
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core][scarthgap][PATCH 01/10] expat: fix CVE-2026-56403
From: Yoann Congal @ 2026-07-19 15:23 UTC (permalink / raw)
To: deeratho, openembedded-core
In-Reply-To: <20260717060437.2910653-2-deeratho@cisco.com>
On Fri Jul 17, 2026 at 8:04 AM CEST, Deepak Rathore via lists.openembedded.org wrote:
> From: Deepak Rathore <deeratho@cisco.com>
>
> These patches apply the upstream fixes shown in [1] and [2], as
> referenced by [3].
>
> Upstream pull request mentioned in [4] contains both the storeAtts fix
> and the related xcsdup overflow hardening so adding both source patches
> explicit, even though the published advisory description names storeAtts
> specifically.
>
> [1] https://github.com/libexpat/libexpat/commit/12dc6d8d3d65f79471a94d8565f6bf1cf245f648
> [2] https://github.com/libexpat/libexpat/commit/147c8f36d6277d5c6011c098370a8362aed47b15
> [3] https://nvd.nist.gov/vuln/detail/CVE-2026-56403
> [4] https://github.com/libexpat/libexpat/pull/1232
>
> Signed-off-by: Deepak Rathore <deeratho@cisco.com>
> ---
> .../expat/expat/CVE-2026-56403_p1.patch | 81 +++++++++++++++++++
> .../expat/expat/CVE-2026-56403_p2.patch | 52 ++++++++++++
> meta/recipes-core/expat/expat_2.6.4.bb | 2 +
> 3 files changed, 135 insertions(+)
> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-56403_p1.patch
> create mode 100644 meta/recipes-core/expat/expat/CVE-2026-56403_p2.patch
>
> [...]
> diff --git a/meta/recipes-core/expat/expat/CVE-2026-56403_p2.patch b/meta/recipes-core/expat/expat/CVE-2026-56403_p2.patch
> new file mode 100644
> index 0000000000..b578cb60cc
> --- /dev/null
> +++ b/meta/recipes-core/expat/expat/CVE-2026-56403_p2.patch
> @@ -0,0 +1,52 @@
> +From 2855ce68a1ce9732267c06734427930364ab66c1 Mon Sep 17 00:00:00 2001
> +From: Sebastian Pipping <sebastian@pipping.org>
> +Date: Fri, 22 May 2026 00:43:52 +0200
> +Subject: [PATCH 02/17] xmlwf: Protect function `xcsdup` from signed integer
> + overflow
> +
> +CVE: CVE-2026-56403
> +Upstream-Status: Backport [https://github.com/libexpat/libexpat/commit/147c8f36d6277d5c6011c098370a8362aed47b15]
> +
> +Backport Changes:
> +- Add stdint.h and convert count and numBytes to size_t because
> + Scarthgap 2.6.4 lacks these upstream prerequisites.
> +
> +(cherry picked from commit 147c8f36d6277d5c6011c098370a8362aed47b15)
> +Signed-off-by: Deepak Rathore <deeratho@cisco.com>
> +---
> + expat/xmlwf/xmlwf.c | 10 ++++++++--
> + 1 file changed, 8 insertions(+), 2 deletions(-)
> +
> +diff --git a/expat/xmlwf/xmlwf.c b/expat/xmlwf/xmlwf.c
> +index fd4fc3f8..7bbdb303 100644
> +--- a/expat/xmlwf/xmlwf.c
> ++++ b/expat/xmlwf/xmlwf.c
> +@@ -45,6 +45,7 @@
> +
> + #include <assert.h>
> + #include <stdio.h>
> ++#include <stdint.h>
Hello,
Same question as the wrynose reviews:
https://lore.kernel.org/all/DK0Y76VFY9IE.2KH0G9SO8XT0U@smile.fr/T/#m9932c3cd0b7d0659653d92b0a3ae69577fb780c8
Since I'm trying to merge the fix from Peter:
[scarthgap][PATCH] expat: patch CVE-2026-41080 - Peter Marko
https://lore.kernel.org/all/20260505205229.2139449-1-peter.marko@siemens.com/
... the new stdint.h include might not be necessary.
Can you follow-up on this series when that merges?
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [wrynose] [PATCH 5/6] curl: fix CVE-2026-6429
From: Yoann Congal @ 2026-07-19 15:12 UTC (permalink / raw)
To: sudumbha, openembedded-core
In-Reply-To: <577721.1783577282244784131@lists.openembedded.org>
On Thu Jul 9, 2026 at 8:08 AM CEST, Sudhir Dumbhare via lists.openembedded.org wrote:
> Hi Yoann,
> Thank you for the review.
>
> I am working on same and will submit an updated patch series.
>
> Thanks & Regards,
> Sudhir
Gentle ping for a v2 of this series. It holds a patch on scarthgap.
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] gnutls: fix for CVE-2026-42011
From: Yoann Congal @ 2026-07-19 15:10 UTC (permalink / raw)
To: Yoann Congal, hprajapati, openembedded-core
In-Reply-To: <DJL1BNT9KYBU.18COZC5THH1NW@smile.fr>
On Mon Jun 29, 2026 at 12:27 AM CEST, Yoann Congal wrote:
> On Thu Jun 25, 2026 at 2:55 PM CEST, Hitendra Prajapati via lists.openembedded.org wrote:
>> Pick patch from [1] & [2] also mentioned at Debian report in [3]
>>
>> [1] https://gitlab.com/gnutls/gnutls/-/commit/1dead2faec6320aaba321eb56f20d442df192b83
>> [2] https://gitlab.com/gnutls/gnutls/-/commit/24713b8c63137ce0665b495d22ccce4f5ce05c84
>> [3] https://security-tracker.debian.org/tracker/CVE-2026-42011
>> [4] https://gitlab.com/gnutls/gnutls/-/work_items/1824
>>
>> Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
>> ---
>
> As far as I know, this fix is also needed on wrynose:
> CVE-2026-42011 is fixed in 3.8.13 per Debian Security Tracker but wrynose has 3.8.12.
>
> Can you send a fix for wrynose so I can take this one for scarthgap?
>
> Thanks!
Here the current state of this series: Hold pending an equivalent merge on wrynose.
v1 series received here:
[OE-core] [wrynose] [PATCH 1/6] curl: ignore CVE-2026-4873
https://lore.kernel.org/all/20260629131453.1077612-1-adongare@cisco.com/
but had reviews and no v2.
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
* Re: [OE-core] [scarthgap][PATCH] gnutls: fix for CVE-2026-42011
From: Yoann Congal @ 2026-07-19 15:02 UTC (permalink / raw)
To: Yoann Congal, hprajapati, openembedded-core
In-Reply-To: <DJL1BNT9KYBU.18COZC5THH1NW@smile.fr>
On Mon Jun 29, 2026 at 12:27 AM CEST, Yoann Congal wrote:
> On Thu Jun 25, 2026 at 2:55 PM CEST, Hitendra Prajapati via lists.openembedded.org wrote:
>> Pick patch from [1] & [2] also mentioned at Debian report in [3]
>>
>> [1] https://gitlab.com/gnutls/gnutls/-/commit/1dead2faec6320aaba321eb56f20d442df192b83
>> [2] https://gitlab.com/gnutls/gnutls/-/commit/24713b8c63137ce0665b495d22ccce4f5ce05c84
>> [3] https://security-tracker.debian.org/tracker/CVE-2026-42011
>> [4] https://gitlab.com/gnutls/gnutls/-/work_items/1824
>>
>> Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
>> ---
>
> As far as I know, this fix is also needed on wrynose:
> CVE-2026-42011 is fixed in 3.8.13 per Debian Security Tracker but wrynose has 3.8.12.
>
> Can you send a fix for wrynose so I can take this one for scarthgap?
>
> Thanks!
Gentle ping for the above
Regards,
--
Yoann Congal
Smile ECS
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox