Cherry-pick patch mentioning this CVE.
(From OE-Core rev: d9d99bd5baddcb0438e0c28ab6e302ee9fa0c327)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 4e01993bf71d3b8e2375ab43857b671738953507)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: f24f2dc0b7504508357cbe5d5f7a577639a6548e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 0c860bf1765b49a7540ae3cb206ce09cf25f30a7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 70a15bc790025e3241274d3e92674928c41537b6)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: f3a14813ed012904e64fd9897ea4ddaf622059dd)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning these CVEs.
(From OE-Core rev: 61268080ba160a4965873ba5aad6ebbfd1ee2fe1)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 120d8cc7b91654557a3101a5f8fda44fb703e5b2)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
It is used to fix multiple CVEs.
(From OE-Core rev: c12baf254a37ff4921c2be0e4d3f626a91980d1a)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2021-46705 was needed only with 2.06
CVE-2023-4692 and CVE-2023-4693 were fixed in NVD DB meanwhile
(From OE-Core rev: fab492f32a8630a353d307119dd4109dac81ad45)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
According to Yocto reference manual, in description of the
IMAGE_LINK_NAME variable, it is said that
It is possible to set this to "" to disable symlink creation,
however, you also need to set :term:`IMAGE_NAME` to still have
a reasonable value e.g.::
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
However, when using following additions in local.conf file:
INHERIT += "cve-check"
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
the implicit symlink creation in cve_check_write_rootfs_manifest leads
to following build failure
$ bitbake core-image-minimal core-image-base
...
ERROR: core-image-base-1.0-r0 do_image_complete: Recipe core-image-base is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
/home/poky/build/tmp/deploy/images/qemux86-64/.json
(matched in manifest-qemux86_64-core-image-minimal.image_complete)
Please adjust the recipes so only one recipe provides a given file.
Mitigate the issue by creating the symlink only in case IMAGE_LINK_NAME
has not been set to empty string.
(From OE-Core rev: 64bfec359bd909761ce0a6a716286d938ed162d1)
(From OE-Core rev: 35e210e3ebe21f1f4466760076b7140618af536e)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
As we just match on product by default, ignore three CVEs which are
for the "Puzzles" WordPress theme by ThemeREX (CPE themerex:puzzles).
(From OE-Core rev: 87326573c82ac1e8dc335319442236ef2341501e)
(From OE-Core rev: 9543945bb935e9a3e2bfbf731412188fc52ad2c9)
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>
A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled.
A machine-in-the-middle attack can be performed by a malicious machine impersonating
a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific
conditions when verifying the host key. For an attack to be considered successful,
the attacker needs to manage to exhaust the client's memory resource first, turning
the attack complexity high.
(From OE-Core rev: 60b5df194a5bea491489fdae2f32e33ffd21c9c7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We've been seeing intermittent failures on Ubuntu 22.04 in oe-selftest which
were problematic to debug. The failure was inside lock_timeout and once that was
identified and the backtrace obtained, the problem becomes clearer:
File "X/bitbake/lib/bb/server/process.py", line 466, in idle_thread_internal
retval = function(self, data, False)
File "X/bitbake/lib/bb/command.py", line 123, in runAsyncCommand
self.cooker.updateCache()
File "X/bitbake/lib/bb/cooker.py", line 1629, in updateCache
self.parser = CookerParser(self, mcfilelist, total_masked)
File "X/bitbake/lib/bb/cooker.py", line 2141, in __init__
self.bb_caches = bb.cache.MulticonfigCache(self.cfgbuilder, self.cfghash, cooker.caches_array)
File "X/bitbake/lib/bb/cache.py", line 772, in __init__
loaded += c.prepare_cache(progress)
File "X/bitbake/lib/bb/cache.py", line 435, in prepare_cache
loaded = self.load_cachefile(progress)
File "X/bitbake/lib/bb/cache.py", line 516, in load_cachefile
progress(cachefile.tell() + previous_progress)
File "X/bitbake/lib/bb/cache.py", line 751, in progress
bb.event.fire(bb.event.CacheLoadProgress(current_progress, cachesize),
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 210, in fire_ui_handlers
_ui_handlers[h].event.send(event)
File "X/bitbake/lib/bb/cooker.py", line 117, in send
str_event = codecs.encode(pickle.dumps(event), \'base64\').decode(\'utf-8\')
File "/usr/lib/python3.10/asyncio/sslproto.py", line 320, in __del__
_warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
File "/usr/lib/python3.10/warnings.py", line 109, in _showwarnmsg
sw(msg.message, msg.category, msg.filename, msg.lineno,
File "X/bitbake/lib/bb/main.py", line 113, in _showwarning
warnlog.warning(s)
File "/usr/lib/python3.10/logging/__init__.py", line 1489, in warning
self._log(WARNING, msg, args, **kwargs)
File "/usr/lib/python3.10/logging/__init__.py", line 1624, in _log
self.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1634, in handle
self.callHandlers(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1696, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 968, in handle
self.emit(record)
File "X/bitbake/lib/bb/event.py", line 778, in emit
fire(record, None)
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 197, in fire_ui_handlers
with bb.utils.lock_timeout(_thread_lock):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "X/bitbake/lib/bb/utils.py", line 1888, in lock_timeout
bb.server.process.serverlog("Couldn\'t get the lock for 5 mins, timed out, exiting. %s" % traceback.format_stack())
or put in simpler terms, whilst sending an event(), an unrelated warning
message happens to be triggered from asyncio:
/usr/lib/python3.10/asyncio/sslproto.py:320: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7f0e797d3100>
which triggers a second event() which can't be sent as we're already
in the critcal section and already hold the lock.
That warning is due to the version of asyncio used on Ubuntu 22.04 with
python 3.10 and that comined with timing issues explains why we don't
see it on other python versions or distros.
We can't handle the second event as the lock is there to serialise the
events. Instead, we queue the event and then process the queue later.
Add a new version of lock_timeout which allows us to handle the situation
more gracefully.
(Bitbake rev: 696c2c1ef095f8b11c7d2eff36fae50f58c62e5e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2c590ff1aff89d23b25ce808650f200013a1e6af)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We never want to exit whilst holding these locks as it deadlocks all python
threads. Add signal blocking around the lock critical part so a signal
shouldn't cause such an exit.
(Bitbake rev: 5cc1dde1ffd9382b3a9e4cc182be067defba16a7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a097755c671e2b530dea6200a94b39fa9dca246c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We should really try and take the lock in the try/finally block so that
in some rare cases such as badly timed interrupt/signal, we always release
the lock.
(Bitbake rev: 5dbbca616a71047fc3573a2be49846d5c9cdd15a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a9eb8bf7174b6962b5ba07192fe95b8c7112d9d2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* Noteworthy changes in release 4.20.0 (2025-02-01) [stable]
- The release tarball is now reproducible.
- We publish a minimal source-only tarball generated by 'git archive'.
- Update gnulib files and various build/maintenance fixes.
- Fix CVE-2024-12133: Potential DoS in handling of numerous SEQUENCE OF or SET
OF elements
License-Update: file COPYING.LESSER renamed to COPYING.LESSERv2 & Copyright year updated to 2025
(From OE-Core rev: fc5814dfa49c67157def00b323656f15e8bc457b)
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Starting from 2023d version, tzcode makefile does not use anymore "cc"
variable for C compiler, due to Makefile refactoring.
Replacing "cc" with "CC" fixes the issue.
(From OE-Core rev: c297d2cd8d28463adca5158c9895f1492754d569)
Signed-off-by: Alessio Cascone <alessio.cascone@vimar.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 b3cdfca5ef84ed2054faef9abddef3aeed930e17)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This was removed in 2019, so swap it for poky-altcfg.
(From yocto-docs rev: f0348f44008b6f89ed1119497fe2dcd230691625)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 7f7f6570befdda280c174a5f9776b20f53f3ea0d)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
core-image-lsb was removed in 2019[1], so remove all of the incredibly
obsolete references in the documentation.
[1] oe-core fb064356af615d67d85b65942103bf943d84d290
(From yocto-docs rev: 05029257d0c5f090d5c0a96c6244bfaf40615178)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 062445a49919eff117b5478c1fb18d125c1f895c)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The libpcre2 is now dlopen'ed, so it is not automatically added to the
RDEPENDS anymore. Add it to the RRECOMMENDS list (and not RDEPENDS as
systemd tags the library as "suggested").
This issue is not on master, the systemd v257 recipe uses a tool that
systemd provides to get this kind of dependencies. But this cannot be
backported to scarthgap as systemd v255 does not have this tool yet.
Cc: Yoann Congal <yoann.congal@smile.fr>
(From OE-Core rev: 45fc7048c511c433ecc23840fe6fdd61f6366a47)
Signed-off-by: Alexis Cellier <alexis.cellier@smile.fr>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A reachable assertion in FFmpeg git-master commit N-113007-g8d24a28d06 allows
attackers to cause a Denial of Service (DoS) via opening a crafted AAC file.
(From OE-Core rev: bf0ad79c46d8a01aafc91620ddf415749aa8849a)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
FFmpeg git-master,N-113007-g8d24a28d06 was discovered to contain a segmentation
violation via the component /libavcodec/jpeg2000dec.c.
(From OE-Core rev: bc9cdf3701b937d40964903a3489898a69525d17)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
FFmpeg git master before commit fd1772 was discovered to contain a NULL pointer
dereference via the component libavformat/mov.c.
(From OE-Core rev: a8331b11d5d7aa8f1997eaa189b74aaab7cc44da)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
FFmpeg git master before commit c08d30 was discovered to contain a NULL pointer
dereference via the component libavformat/mov.c.
(From OE-Core rev: abc6b3180b87c665ff04204b7163d1f074d99747)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2025-0725 can only trigger for curl when using a runtime
zlib version 1.2.0.3 or older and scarthgap supports
zlib 1.3.1 version, hence ignore cve for scarthgap
https://curl.se/docs/CVE-2025-0725.html
(From OE-Core rev: 8c3b4a604b40260e7ca9575715dd8017e17d35c0)
Signed-off-by: Poonam Jadhav <poonam.jadhav@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
sshd(8) in OpenSSH versions 9.5p1 to 9.9p1
(inclusive) is vulnerable to a memory/CPU denial-of-service related
to the handling of SSH2_MSG_PING packets. This condition may be
mitigated using the existing PerSourcePenalties feature.
Upstream-Status: Backport [6ce00f0c2e]
(From OE-Core rev: 7360f3998939e202f9611644a8bed0c3fe0c782a)
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
At the end of this function, self.overrides is cleared, which means we'll
construct a new self.overrides after this call. And a new self.overrides
will give out different expand_cache, so the old expand_cache should also
be cleared to avoid any wrong value.
Currently, there's a problem revealed by recent recipe specific virtual
provider patch. If we enable multilib and set "OVERRIDES:prepend" in local.conf,
things don't work.
Here's the error message:
ERROR: Nothing PROVIDES 'lib32-gcc-cross-x86_64'
Below are reproduce steps:
1. Add in local.conf the following lines:
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32"
OVERRIDES:prepend = "some-override:"
(Note that using :append and :remove also reproduces the issue.)
2. bitbake -n lib32-sysstat
(bitbake -n core-image-minimal also reproduces the issue)
The expandWithRefs calls getVar, which fills expand_cache. So when setting
OVERRIDES:prepend, this will fill the expand_cache. When overridevars are updated,
if we don't clear expand_cache, we'll retrieve wrong values.
Previously, things happened to work because there's a call to expand
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc, which in turn expands
TARGET_VENDOR. Now what we expand is PREFERRED_PROVIDER_ virtual/cross-cc,
so the problem is revealed.
(Bitbake rev: 7375d32e8c1af20c51abec4eb3b072b4ca58b239)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When var matches __setvar_regexp__, which has the value as below,
__setvar_regexp__ = re.compile(r'(?P<base>.*?)(?P<keyword>:append|:prepend|:remove)(:(?P<add>[^A-Z]*))?$')
the keyword will not be __doc__ or __module__ and var will always
contain ":".
(Bitbake rev: 9cac695951d0fd587063b250bfc8ef0f87acad18)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The non-greedy modifier suffix ? is not necessary here because } is
not in the character set [a-zA-Z0-9\-_+./~:].
(Bitbake rev: aae570b7f051fc5deee7a1712a02ed92498a4461)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This fixes the following error when calling 'bitbake-dumpsig' or
'bitbake-diffsigs' when having only a single sigfile available:
| Traceback (most recent call last):
| File "[..]/poky/bitbake/bin/bitbake-dumpsig", line 171, in <module>
| files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "[..]/poky/bitbake/bin/bitbake-dumpsig", line 83, in find_siginfo_task
| sig2 = latestsigs[1]
| ~~~~~~~~~~^^^
| IndexError: list index out of range
Handle this by adding (and returning) the path for the second sigfile
only if one is found. This way it will work for both diffsigs and
dumpsig use case.
The calling argparse code already deals with find_siginfo_task()
returning only a single file.
For 'bitbake-dumpsig' it will just dump the single sigfile, for
'bitbake-diffsigs' it will emit a proper error message again:
| ERROR: Only one matching sigdata file found for the specified task (systemd configure)
(cherry picked from commit 25057d33e9131f3214a06bbb316c916c744f8f03)
(Bitbake rev: 4e443aeab9096b41c9e5ba41cd21027ecaa20285)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Patrick Vogelaar <patrick.vogelaar@belden.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
