Cross task outputs can call native dependencies and even when cross
recipe output doesn't change it might produce different results when
the called native dependency is changed, e.g. clang-cross-${TARGET_ARCH}
contains symlink to clang binary from clang-native, but when clang-native
outhash is changed, clang-cross-${TARGET_ARCH} will still be considered
equivalent and target recipes aren't rebuilt with new clang binary, see
work around in https://github.com/kraj/meta-clang/pull/1140 to make target
recipes to depend directly not only on clang-cross-${TARGET_ARCH} but
clang-native as well.
I have added a small testcase in meta-selftest which demostrates this issue.
Not included in this change, but will send it if useful.
openembedded-core $ ls -1 meta-selftest/recipes-devtools/hashequiv-test/
print-datetime-link-cross.bb
print-datetime-link-native.bb
print-datetime-native.bb
print-datetime-usecross.bb
print-datetime-usenative.bb
print-datetime-native provides script which prints defined PRINT_DATETIME variable.
print-datetime-link-native and print-datetime-link-cross both provide a symlink to
the script from print-datetime-native.
print-datetime-usenative and print-datetime-usecross are target recipes using the
native and cross versions of print-datetime-link-* recipe.
# clean build all is rebuilt:
$ bitbake -k print-datetime-usenative print-datetime-usecross
WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_05
WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_05
WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_05
WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_05
WARNING: print-datetime-usecross-1.0-r0 do_install: print-datetime-usecross current DATETIME from print-datetime-link is 2025-11-13_20_05
# keep sstate-cache and hashserv.db:
# print-datetime-usenative is correctly rebuilt, because print-datetime-link-native has different hash (because print-datetime-native hash changed)
# print-datetime-usecross wasn't rebuilt, because print-datetime-link-cross-x86_64 doesn't include the changed hash of print-datetime-native
$ bitbake -k print-datetime-usenative print-datetime-usecross
WARNING: print-datetime-native-1.0-r0 do_install: print-datetime-native current DATETIME in script is 2025-11-13_20_07
WARNING: print-datetime-link-native-1.0-r0 do_install: print-datetime-link-native current DATETIME in symlink is 2025-11-13_20_07
WARNING: print-datetime-link-cross-x86_64-1.0-r0 do_install: print-datetime-link-cross-x86_64 current DATETIME in symlink is 2025-11-13_20_07
WARNING: print-datetime-usenative-1.0-r0 do_install: print-datetime-usenative current DATETIME from print-datetime-link is 2025-11-13_20_07
It's because print-datetime-link-cross-x86_64 depsig doesn't include print-datetime-native signature:
Moritz Haase [Mon, 22 Dec 2025 11:24:54 +0000 (12:24 +0100)]
curl: Use host CA bundle by default for native(sdk) builds
Fixes YOCTO #16077
Commit 0f98fecd (a backport of 4909a46e) broke HTTPS downloads in opkg in the
SDK, they now fail with:
> SSL certificate problem: self-signed certificate in certificate chain
The root cause is a difference in the handling of related env vars between
curl-cli and libcurl. The CLI will honour CURL_CA_BUNDLE and SSL_CERT_DIR|FILE
(see [0]). Those are set in the SDK via env setup scripts like [1], so curl
continued to work. The library however does not handle those env vars. Thus,
unless the program utilizing libcurl has implemented a similar mechanism itself
and configures libcurl accordingly via the API (like for example Git in [2] and
[3]), there will be no default CA bundle configured to verify certificates
against.
Opkg only supports setting the CA bundle path via config options 'ssl_ca_file'
and 'ssl_ca_path'. Upstreaming and then backporting a patch to add env var
support is not a feasible short-time fix for the issue at hand. Instead it's
better to ship libcurl in the SDK with a sensible built-in default - which also
helps any other libcurl users.
This patch is based on a proposal by Peter.Marko@siemens.com in the related
mailing list discussion at [4].
Enrico Jörns [Tue, 16 Dec 2025 14:15:13 +0000 (15:15 +0100)]
cml1.bbclass: use consistent make flags for menuconfig
The class called 'make menuconfig' without any of the make variables and
options set in EXTRA_OEMAKE, resulting in a quite different build
environment than actually intended.
For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use
consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to
KCONFIG_CONFIG_COMMAND.
Instead of fixing this individually for additional recipes, we simply
include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default.
For most class users, this change is directly visible in the generated
.config file:
* For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected
the host GCC version before where it now correctly reflects the target
toolchain's GCC.
* For u-boot, also the "Compiler: " line at the beginning of the .config
now prints the target toolchain instead of the host ones.
* The kernel had this already set.
* busybox did not produce any difference.
Note that these projects might base some compile-time decisions on e.g.
the actual compiler version used. Having the wrong one in the
menuconfig-generated .config affects at least the visibility and
consistency.
Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de> Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Steve Sakoman <steve@sakoman.com>
oeqa/selftest: oe-selftest: Add SPDX tests for kernel config and PACKAGECONFIG
Add test_kernel_config_spdx and test_packageconfig_spdx to verify
SPDX document generation includes kernel configuration and package
feature metadata when enabled.
Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2f0ab110d7521510c60e0493ef3cb021130758cd) Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
spdx30_tasks: Add support for exporting PACKAGECONFIG to SPDX
Introduce the SPDX_INCLUDE_PACKAGECONFIG variable, which when enabled causes
PACKAGECONFIG features to be recorded in the SPDX document as build parameters.
Each feature is recorded as a DictionaryEntry with key PACKAGECONFIG:<feature>
and value enabled or disabled, depending on whether the feature is active in
the current build.
This makes the build-time configuration more transparent in SPDX output and
improves reproducibility tracking.
This makes the build-time configuration more transparent in SPDX output and
improves reproducibility tracking. In particular, it allows consumers of the
SBOM to identify enabled/disabled features that may affect security posture
or feature set.
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7ec61ac40345a5c0ef1ce20513a4596989c91ef4) Signed-off-by: Steve Sakoman <steve@sakoman.com>
kernel.bbclass: Add task to export kernel configuration to SPDX
Introduce a new bitbake task do_create_kernel_config_spdx that extracts
the kernel configuration from ${B}/.config and exports it into the
recipe's SPDX document as a separate build_Build object.
The kernel config parameters are stored as SPDX DictionaryEntry objects
and linked to the main kernel build using an ancestorOf relationship.
This enables the kernel build's configuration to be explicitly captured
in the SPDX document for compliance, auditing, and reproducibility.
The task is gated by SPDX_INCLUDE_KERNEL_CONFIG (default = "0").
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 228a968e7c47d811c06143279bdb0f9c5f374bef) Signed-off-by: Steve Sakoman <steve@sakoman.com>
Mingli Yu [Thu, 18 Dec 2025 07:27:36 +0000 (15:27 +0800)]
ruby: Upgrade 3.3.5 -> 3.3.10
Per ruby maintenance policy [1], the 3.3.x branch should be still in normal
maintenance, so upgrade to the latest version 3.3.10 to fix many security
issues and bugs.
Remove the fix for CVE-2025-27219, CVE-2025-27220 and CVE-2025-27221 as
these fixes have been included in the new version.
Yash Shinde [Fri, 19 Dec 2025 09:50:16 +0000 (01:50 -0800)]
binutils: fix CVE-2025-11840
CVE-2025-11840
PR 33455
[BUG] A SEGV in vfinfo at ldmisc.c:527
A reloc howto set up with EMPTY_HOWTO has a NULL name. More than one
place emitting diagnostics assumes a reloc howto won't have a NULL
name.
Yash Shinde [Fri, 19 Dec 2025 09:50:15 +0000 (01:50 -0800)]
binutils: fix CVE-2025-11839
CVE-2025-11839
PR 33448
[BUG] Aborted in tg_tag_type at prdbg.c:2452
Remove call to abort in the DGB debug format printing code, thus allowing
the display of a fuzzed input file to complete without triggering an abort.
Since x86 .eh_frame section may reference _GLOBAL_OFFSET_TABLE_, keep
_GLOBAL_OFFSET_TABLE_ if there is dynamic section and the output
.eh_frame section is non-empty.
Backport a patch from upstream to fix CVE-2025-11494
Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a]
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Daniel Turull [Wed, 17 Dec 2025 09:22:24 +0000 (10:22 +0100)]
cmake-native: fix CVE-2025-9301
Add fix for native recipe, since previous commit for cmake missed it. 5d8a6fb52c cmake: fix CVE-2025-9301
CC: Saravanan <saravanan.kadambathursubramaniyam@windriver.com> CC: Steve Sakoman <steve@sakoman.com> Signed-off-by: Daniel Turull <daniel.turull@ericsson.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
This introduced a breaking change which is not suitable for backport to
stable LTS branches.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Peter Marko [Mon, 8 Dec 2025 11:27:14 +0000 (12:27 +0100)]
libmicrohttpd: disable experimental code by default
Introduce new packageconfig to explicitly avoid compilation of
experimental code. Note that the code was not compiled by default also
before this patch, this now makes it explicit and makes it possible to
check for the flags in cve-check code.
This is less intrusive change than a patch removing the code which was
rejected in patch review.
This will solve CVE-2025-59777 and CVE-2025-62689 as the vulnerable code
is not compiled by default.
Set appropriate CVE status for these CVEs based on new packageconfig.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Moritz Haase [Fri, 28 Nov 2025 13:19:23 +0000 (14:19 +0100)]
curl: Ensure 'CURL_CA_BUNDLE' from host env is indeed respected
Due to what looks like a copy'n'paste mistake, the environment setup script
might override 'CURL_CA_BUNDLE' from the host env instead of leaving it
untouched. Fix that.
Rootfs VEX file is created by gathering files from CVE_CHECK_DIR
(deploy directory), however recipes generate the files only in
CVE_CHECK_DIR (log directory).
This make the rootfs VEX be always empty without any message.
The code is copied from cve_check class, which writes to both, so let
keep them aligned and make also vex write both files.
Also add a warning for case that a cve file would be still missing.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ee6541d0940c65685aaafd7d41a59a9406392e7d) Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
If spdx is generated without inheriting cve/vex classes (which is poky
default), only explicitly set CVE_STATUS fields are handled.
Calculated ones (e.g. from CVE_STATUS_GROUPS) are ignored.
Fix this by expanding the CVE_STATUS in spdx classes.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ead9c6a8770463c21210a57cc5320f44f7754dd3) Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
cve-check: extract extending CVE_STATUS to library function
The same code for extending CVE_STATUS by CVE_CHECK_IGNORE and
CVE_STATUS_GROUPS is used on multiple places.
Create a library function to have the code on single place and ready for
reuse by additional classes.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 45e18f4270d084d81c21b1e5a4a601ce975d8a77) Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
The "vex" class generates the minimum information that is necessary
for VEX generation by an external CVE checking tool. It is a drop-in
replacement of "cve-check". It uses the same variables from recipes
to make the migration and backporting easier.
The goal of this class is to allow generation of the CVE list of
an image or distribution on-demand, including the latest information
from vulnerability databases. Vulnerability data changes every day,
so a status generated at build becomes out-of-date very soon.
Research done for this work shows that the current VEX formats (CSAF
and OpenVEX) do not provide enough information to generate such
rolling information. Instead, we extract the needed data from recipe
annotations (package names, CPEs, versions, CVE patches applied...)
and store for later use in the format that is an extension of the
CVE-check JSON output format.
This output can be then used (separately or with SPDX of the same
build) by an external tool to generate the vulnerability annotation
and VEX statements in standard formats.
When back-porting this feature, the do_generate_vex() had to be modified
to use the "old" get_patched_cves() API.
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com> Signed-off-by: Samantha Jalabert <samantha.jalabert@syslinbit.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6352ad93a72e67d6dfa82e870222518a97c426fa) Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
spdx30: provide all CVE_STATUS, not only Patched status
In scarthgap, the `oe.cve_check.get_patched_cves()` method only returns
CVEs with a "Patched" status. We want to retrieve all annotations,
including those with an "Ignored" status. Therefore, to avoid modifying
the current API, we integrate the logic for retrieving all CVE_STATUS
values directly into `spdx30_task`.
Signed-off-by: Benjamin Robin (Schneider Electric) <benjamin.robin@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Peter Marko [Thu, 20 Nov 2025 08:25:11 +0000 (09:25 +0100)]
oeqa/sdk/buildepoxy: skip test in eSDK
Currently meson inside eSDKs only works with fully populated eSDKs,
but our testing uses minimal eSDKS, so skip the test if the eSDK is a
minimal build. A bug has been filed to resolve this.
Peter Marko [Thu, 13 Nov 2025 12:28:05 +0000 (13:28 +0100)]
oeqa: fix package detection in go sdk tests
The test are skipped if architecture contains dash because TARGET_ARCH
contains underscore while package name contains dash. Here the
translation needs to be done.
Note that poky distro default arch has dash:
MACHINE="qemux86-64"
TARGET_ARCH="x86_64"
ERROR: Nothing PROVIDES 'go-cross-canadian-x86_64'. Close matches:
gcc-cross-canadian-x86-64
gdb-cross-canadian-x86-64
go-cross-canadian-x86-64
TRANSLATED_TARGET_ARCH="x86-64"
Quoting meta/classes-recipe/cross-canadian.bbclass:
TRANSLATED_TARGET_ARCH is added into PN
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Osama Abdelkader [Thu, 13 Nov 2025 12:28:02 +0000 (13:28 +0100)]
go: add sdk test
- Add meta/lib/oeqa/sdk/cases/go.py with GoCompileTest and GoHostCompileTest classes
- Test validates Go cross-compilation toolchain functionality
- Includes native compilation, cross-compilation, and Go module support
- Uses dynamic architecture detection for portability
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
goarch.bbclass: do not leak TUNE_FEATURES into crosssdk task signatures
The default assignments look like this:
TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
TUNE_FEATURES is a target-specific variable, and so should be used
only for target builds. The change is similar to what is already done
for native packages.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Ross Burton [Thu, 13 Nov 2025 12:27:59 +0000 (13:27 +0100)]
oe/sdk: fix empty SDK manifests
The SDK manifests are generated by listing the sstate was that used, but
it hardcodes that the sstate data filenames end in .tgz.
This has not been the case since sstate switched to Zstd[1] in 2021,
which meant that all of the tests which checked for packages existing
were being skipped as the manifests were empty. For example, see a
representative core-image-sato eSDK test run[2]:
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Ross Burton [Thu, 13 Nov 2025 12:27:58 +0000 (13:27 +0100)]
testsdk: allow user to specify which tests to run
Following the usage of TEST_SUITES in testimage, add TESTSDK_SUITES to
specify the list of tests to execute. By default the variable is empty,
which means to run all discovered tests.
This makes it easier to work on a single test without having to run all
of the tests.
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Gyorgy Sarvari [Thu, 20 Nov 2025 13:14:35 +0000 (14:14 +0100)]
glslang: fix compiling with gcc15
Backport a patch that fixes a compilation failure with gcc15:
| .../git/SPIRV/SpvBuilder.h:238:30: error: ‘uint32_t’ has not been declared
| 238 | Id makeDebugLexicalBlock(uint32_t line);
| | ^~~~~~~~
| .../git/SPIRV/SpvBuilder.h:64:1: note: ‘uint32_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Ovidiu Panait [Mon, 10 Nov 2025 22:27:10 +0000 (00:27 +0200)]
rust-target-config: fix nativesdk-libstd-rs build with baremetal
If TCLIBC='baremetal' is set in local.conf, nativesdk-libstd-rs build fails
with:
| error[E0412]: cannot find type `c_char` in the crate root
| --> /usr/src/debug/libstd-rs/1.75.0/rustc-1.75.0-src/vendor/libc/src/unix/mod.rs:56:29
| |
| 6 | pub type c_schar = i8;
| | ---------------------- similarly named type alias `c_schar` defined here
| ...
| 56 | pub gr_name: *mut ::c_char,
| | ^^^^^^
This happens because rust_gen_target() sets os="none" when TCLIBC is
'baremetal' - even for nativesdk targets. However, nativesdk packages are
built against glibc, so the correct 'os' value should be "linux".
Fix this by setting the os field based on {TARGET,HOST,BUILD}_OS variables,
as it is already done in rust_base_triple(), instead of relying on TCLIBC.
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(master rev: 3eaf2cd5647585a1e6df03fc20e2753da27bb692) -- backport Signed-off-by: Stefan Ghinea <stefan.ghinea@windriver.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Yogita Urade [Wed, 19 Nov 2025 11:04:41 +0000 (16:34 +0530)]
xwayland: fix CVE-2025-62231
A flaw was identified in the X.Org X serverâ\x80\x99s X Keyboard
(Xkb) extension where improper bounds checking in the XkbSetCompatMap()
function can cause an unsigned short overflow. If an attacker sends
specially crafted input data, the value calculation may overflow,
leading to memory corruption or a crash.
Yogita Urade [Wed, 19 Nov 2025 11:04:40 +0000 (16:34 +0530)]
xwayland: fix CVE-2025-62230
A flaw was discovered in the X.Org X serverâ\x80\x99s X Keyboard
(Xkb) extension when handling client resource cleanup. The software
frees certain data structures without properly detaching related
resources, leading to a use-after-free condition. This can cause
memory corruption or a crash when affected clients disconnect.
Yogita Urade [Wed, 19 Nov 2025 11:04:39 +0000 (16:34 +0530)]
xwayland: fix CVE-2025-62229
A flaw was found in the X.Org X server and Xwayland when processing
X11 Present extension notifications. Improper error handling during
notification creation can leave dangling pointers that lead to a
use-after-free condition. This can cause memory corruption or a crash,
potentially allowing an attacker to execute arbitrary code or cause a
denial of service.
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2c
https://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
Signed-off-by: Bruno VERNAY <bruno.vernay@se.com> Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Hongxu Jia [Tue, 18 Nov 2025 12:09:48 +0000 (13:09 +0100)]
spdx30: Provide software_packageUrl field in SPDX 3.0 SBOM
Define var-SPDX_PACKAGE_URL to provide software_packageUrl field [1][2]
in SPDX 3.0 SBOM, support to override with package name
SPDX_PACKAGE_URL:<pkgname>
Currently, the format of purl is not defined in Yocto, set empty for now
until we have a comprehensive plan for what Yocto purls look like.
But users could customize their own purl by setting var-SPDX_PACKAGE_URL
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
Peter Marko [Tue, 18 Nov 2025 12:08:39 +0000 (13:08 +0100)]
spdx30: fix cve status for patch files in VEX
This commit fixes commit 08595b39b46ef2bf3a928d4528292ee31a990c98
which adapts vex creation between function create_spdx where all changes
were backported and funtion get_patched_cves where changes were not
backported.
CVE patches were previously ignored as they cannot be decoded from
CVE_STATUS variables and each caused a warning like:
WARNING: ncurses-native-6.4-r0 do_create_spdx: Skipping CVE-2023-50495 — missing or unknown CVE status
Master branch uses fix-file-included for CVE patches however since
cve-check-map.conf was not part of spdx-3.0 backport, closest one
available (backported-patch) was implemented.
Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
As the poky repository is no longer used, measurements are indexed using
the oe-core commit. But as bitbake, oe-core and meta-yocto are now
retrieved from separate gits, while measuring performances for a given branch
at some time interval, we can get the same commit for oe-core but
different ones for bitbake or meta-yocto. As a consequence, metadata
associated with the same index (oe-core commit) might differ.
To work around this, relax the equality checks for commit, commit_time
and commit_count since they might no longer match.
Ideally we'd group them into separate results but for now, treat them
as being the same.
[Based on work from Mathieu Dubois-Briand but fixed differently] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e7dc42e30c76bf0fbb4d3cc019bbec675bac55fa) Signed-off-by: Steve Sakoman <steve@sakoman.com>
Joshua Watt [Fri, 7 Nov 2025 13:14:50 +0000 (14:14 +0100)]
oeqa: spdx: Add tar test for SPDX 2.2
The base-files test for SPDX 2.2 did not give good coverage, since
base-files doesn't have any dependencies. Add building tar as another
test which more fully exercises the code
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
spdx30_tasks: adapt CVE handling to new cve-check API
Changes to cve-check (see poky commit fb3f440b7d8,
"cve-check: annotate CVEs during analysis") modified the
get_patched_cves() API to return a set of CVE IDs instead of a
dictionary of CVE metadata.
The SPDX 3 backport still expected a dictionary and attempted to call
.items(), leading to:
AttributeError: 'set' object has no attribute 'items'
This patch updates the SPDX3 code to iterate directly over the CVE IDs
and use `oe.cve_check.decode_cve_status()` to retrieve the mapping,
detail, and description for each CVE. This restores compatibility with
the updated CVE API and matches the behavior of SPDX3 handling on
Walnascar.
A warning is logged if a CVE has missing or unknown status.
Joshua Watt [Fri, 7 Nov 2025 13:14:48 +0000 (14:14 +0100)]
spdx 3.0: Rework how SPDX aliases are linked
The SPDX code needs to be able to look up an Element by its SPDX ID,
locating the file that (should) contain the SPDX ID and opening it for
parsing. Previously, the code would do this be hashing each Element
SPDX ID and Alias, and the creating a symbolic link to the file that
contains the element with a name of the hash.
This worked well as it was possible to look up any arbitrary SPDX ID or
alias by simply hashing it and following the symbolic link to get the
file. However, the down side of this approach is that it creates a lot
of symbolic links, since it will make one or two per Element in the
document. This can be a problem when using SPDX_INCLUDE_SOURCES, for
example.
This change reworks this strategy so that the only Element that gets a
symbolic link based on the hash is the singular SpdxDocument that is
create for each file. All other Elements are assigned an alias with a
special prefix that encodes the hash of SpdxDocument alias. Thus, when
attempting to look up an arbitrary alias, the code sees the special
prefix, extract the hash, opens the file based on the symlink with that
hash name, then finds the matching Element in the file. This drastically
reduces the number of symbolic links by making only one per file.
This also means that the custom link extension can be removed since it
is now superfluous.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 838d64c09657ac53175737fc4e7fd6f01f3dcf47) Signed-off-by: Kamel Bouhara (Schneider Electric) <kamel.bouhara@bootlin.com>
Joshua Watt [Fri, 7 Nov 2025 13:14:47 +0000 (14:14 +0100)]
lib: oeqa: spdx: Add tests for extra options
Adds a test for several of the extra options provided by the SPDX
classes. In particular, these are the options that can produce
non-reproducible results, so are not enabled by default in OE core. This
test takes care to configure the build so that the tests do run in a
reproducible manner so that pre-built test objects can be pulled from
sstate
classes/create-spdx-2.2: align DEPLOY_DIR_SPDX with SPDX_VERSION layout
Upstream commit 544d46e4169a ("selftest/spdx: Fix for SPDX_VERSION addition")
updated the selftests to expect SPDX artifacts under:
${DEPLOY_DIR}/spdx/${SPDX_VERSION}/
However, in this branch the effective SPDX output was still being
written to:
${DEPLOY_DIR}/spdx/${PACKAGE_ARCH}/
without the version subdirectory. This caused SPDX selftests such as
test_spdx_tar to fail with missing file errors, e.g.:
AssertionError: .../deploy/spdx/SPDX-1.1/core2-64/packages/tar.spdx.json does not exist
Update create-spdx-2.2.bbclass so that DEPLOY_DIR_SPDX includes
${SPDX_VERSION}, matching the expected deploy structure and restoring
successful SPDX selftests.
Downstream tasks may want to know what image files were written so write
out a manifest in do_image_complete. The format of the manifest is the
same as the one in image.bbclass
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Watt [Fri, 7 Nov 2025 13:14:41 +0000 (14:14 +0100)]
classes-recipe/image: Add image file manifest
Downstream tasks may want to know what image files were written by the
do_image family of tasks (e.g. SPDX) so have each task write out a
manifest file that describes the files it produced, then aggregate them
in do_image_complete
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5e55ed4c5b9d5af3c96b82805af34af1512fc3d1)
Joshua Watt [Fri, 7 Nov 2025 13:14:38 +0000 (14:14 +0100)]
classes-global/staging: Exclude do_create_spdx from automatic sysroot extension
do_create_spdx is a outlier in that it doesn't need the RSS to be
extended just because it depends on do_populate_sysroot. In fact, it
only depends on do_populate_sysroot so it can see the actual recipes
sysroot, and attempting to extend the sysroot can cause problems for
some recipes (e.g. if a recipe does do_populate_sysroot[noexec] = "1")
As such, explicitly exclude do_create_spdx from extending the sysroot
just because it depends on do_populate_sysroot.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Watt [Fri, 7 Nov 2025 13:14:37 +0000 (14:14 +0100)]
classes-global/license: Move functions to library code
Moves several of the functions in license.bbclass to be library code
New function dependencies were manually verified using bitbake-dumpsigs
to ensure that bitbake identified the same dependencies even though they
are now in library code (although the new function names mean that the
task hashes still change)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0333e04e353991260c5f67a72f80f3ab9dcf526a)
Richard Purdie [Mon, 10 Nov 2025 13:59:03 +0000 (13:59 +0000)]
oeqa/selftest/devtool: Update after upstream repo changes
The upstream changed the branch name, moving to archive/ so we need to
update too. Take the opportunity to match the new location too to avoid
the redirect.
We could use a different branch but upstream would probably eventually
rename that too so this may last longer.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 478a645bad150f04dee1b0085c4542c2eefe7007) Signed-off-by: Steve Sakoman <steve@sakoman.com>
Gyorgy Sarvari [Mon, 10 Nov 2025 10:21:47 +0000 (23:21 +1300)]
ca-certificates: fix on-target postinstall script
When the package is installed directly on the machine (instead of
installing it in the rootfs directly), the postinstall script fails with
the following error:
/usr/sbin/update-ca-certificates: line 75: shift: shift count out of range
The reason is that the "update-ca-certificates" script is executed with
the "--sysroot" argument, and as the sysroot $D is passed. However on the
target system this variable doesn't exist, so the argument is passed without
this mandatory value, and the execution fails.
To avoid this error, check if the $D variable exists, and pass the --sysroot
argument only when it does.
Reported-by: WXbet <Wxbet@proton.me> Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cf39461e97098a1b28693299677888ba7e8bfccf) Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
ca-certificates: submit sysroot patch upstream, drop default-sysroot.patch
ca-certificates/0002-update-ca-certificates-use-SYSROOT.patch
was using a non-standard environment variable, and was replaced
with a patch that adds a command line option (and then this
was submitted upstream). ca-certificates recipe was tweaked accordingly,
and nothing else in core or meta-oe is using update-ca-certificates.
Drop default-sysroot.patch as the use case is unclear: sysroot
is explicitly specified in all known invocations of update-ca-certificate,
and if there's a place where it isn't, then update-ca-certificates
will error out trying to write to /etc, and should be fixed to
explicitly specify the sysroot.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 90d9f0ba674d4fe8e9291f0513c13dff3775c545) Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
git repo no longer has tags for recent versions which means
we had missed several of them, and wouldn't be able to get
notifications about any future releases.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 81f013fd1312551628701bf36ac62746a2606dbd) Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
The Reader.ReadResponse function constructs a response string through
repeated string concatenation of lines. When the number of lines in a
response is large, this can cause excessive CPU consumption.