A flaw was found in the QEMU disk image utility (qemu-img) 'info' command. A specially crafted image file containing a `json:{}` value describing block devices in QMP could cause the qemu-img process on the host to consume large amounts of memory or CPU time, leading to denial of service or read/write to an existing external file.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-4467
Upstream commits:
bd385a52982eb42a728d7e1110664e83930780327ead946998
(From OE-Core rev: c23ad8c89c3dd5b6004677cd0b534e22a293134d)
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in the QEMU NBD Server. This vulnerability allows a denial of service (DoS) attack
via improper synchronization during socket closure when a client keeps a socket open as the server
is taken offline.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-7409
Upstream Patches:
fb1c2aaa98c8a76dbd90b9b72cb3ce3e7ef738c8
(From OE-Core rev: d84ab04dc66cb83638f96fcd2f4c67e67489c410)
Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backport PACKAGECONFIG[editline] from Scarthgap to Kirkstone
because libedit has feature parity with readline but is more
permissively licensed (BSD verses GPLv3). This patch provides
means of enabling editline in a distribution without GPLv3 and
in this case improves Python REPL keyboard support.
(From OE-Core rev: 12dc7d2081a1aaec90ffb3ed6718d757ce14b5ab)
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This package can be built using pep517 classes now.
(From OE-Core rev: 6c1000a2bbfe5e618e42bc5be2058332337d4177)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a32fa3e64d1daf5846c29403e9f258aea42212d3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Certifi is a curated collection of Root Certificates for validating the
trustworthiness of SSL certificates while verifying the identity of TLS
hosts. Certifi starting in 2021.05.30 and prior to 2024.07.4 recognized
root certificates from `GLOBALTRUST`. Certifi 2024.07.04 removes root
certificates from `GLOBALTRUST` from the root store. These are in the
process of being removed from Mozilla's trust store. `GLOBALTRUST`'s root
certificates are being removed pursuant to an investigation which
identified "long-running and unresolved compliance issues."Certifi is a
curated collection of Root Certificates for validating the trustworthiness
of SSL certificates while verifying the identity of TLS hosts. Certifi
starting in 2021.05.30 and prior to 2024.07.4 recognized root certificates
from `GLOBALTRUST`. Certifi 2024.07.04 removes root certificates from
`GLOBALTRUST` from the root store. These are in the process of being removed
from Mozilla's trust store. `GLOBALTRUST`'s root certificates are being
removed pursuant to an investigation which identified "long-running and
unresolved compliance issues."
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-39689
Upstream-patch:
bd8153872e
(From OE-Core rev: 96c1e12dc6cb4c321a09a6ddcc4c9f27c30b4564)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The archive/zip package's handling of certain types of invalid zip files
differs from the behavior of most zip implementations. This misalignment
could be exploited to create an zip file with contents that vary depending
on the implementation reading the file. The archive/zip package now rejects
files containing these errors.
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-24789
Upstream-patch:
c8e40338cf
(From OE-Core rev: f198fdc392c6e3b99431383ab6577749e83f1cb3)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Debian 12 no longer supports replacing dash with bash as default shell.
Therefore to achieve compatibility with Debian 12, all bashisms need
to be removed.
Shell comparison via == gives an error with dash and thus the condition
is always false.
(From OE-Core rev: 3723b26f82219ff71823335d550dbf29086d63d4)
(From OE-Core rev: c6cafd2aa50357c80fbab79741d575ff567c5766)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Switch to use flit core since upstream changed.
They also changed the capitalisation under pypi.
The license didn't change but the file was renamed, probably as it wasn't
rst.
(From OE-Core rev: 58ee84c274b0c93902aad5d4f434daec5da55134)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e352680528b18c3cdae26233bef7cddc2771d42d)
Upgrade fixes CVE-2024-34064
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A buffer-overread issue was discovered in StringIO 3.0.1, as
distributed in Ruby 3.0.x through 3.0.6 and 3.1.x through
3.1.4. The ungetbyte and ungetc methods on a StringIO can
read past the end of a string, and a subsequent call to
StringIO.gets may return the memory value. 3.0.3 is the main
fixed version; however, for Ruby 3.0 users, a fixed version
is stringio 3.0.1.1, and for Ruby 3.1 users, a fixed version
is stringio 3.0.1.2.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-27280
(From OE-Core rev: 729310d17310dff955c51811ff3339fdbc017b95)
Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2024-32002:
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4,
2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be
crafted in a way that exploits a bug in Git whereby it can be fooled into
writing files not into the submodule's worktree but into a `.git/` directory.
This allows writing a hook that will be executed while the clone operation
is still running, giving the user no opportunity to inspect the code that is
being executed. The problem has been patched in versions 2.45.1, 2.44.1,
2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is
disabled in Git (e.g. via `git config --global core.symlinks false`), the
described attack won't work. As always, it is best to avoid cloning
repositories from untrusted sources.
CVE-2024-32004:
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4,
2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare a local repository
in such a way that, when cloned, will execute arbitrary code during the
operation. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4,
2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid cloning repositories
from untrusted sources.
CVE-2024-32020:
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4,
2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files
into the target repository's object database when source and target repository
reside on the same disk. If the source repository is owned by a different user,
then those hardlinked files may be rewritten at any point in time by the
untrusted user. Cloning local repositories will cause Git to either copy or
hardlink files of the source repository into the target repository. This
significantly speeds up such local clones compared to doing a "proper" clone and
saves both disk space and compute time. When cloning a repository located on the
same disk that is owned by a different user than the current user we also end up
creating such hardlinks. These files will continue to be owned and controlled by
the potentially-untrusted user and can be rewritten by them at will in the
future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2,
2.41.1, 2.40.2, and 2.39.4.
CVE-2024-32021:
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4,
2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that
contains symlinks via the filesystem, Git may create hardlinks to arbitrary
user-readable files on the same filesystem as the target repository in the
`objects/` directory. Cloning a local repository over the filesystem may
creating hardlinks to arbitrary user-owned files on the same filesystem in the
target Git repository's `objects/` directory. When cloning a repository over the
filesystem (without explicitly specifying the `file://` protocol or `--no-local`),
the optimizations for local cloning will be used, which include attempting to
hard link the object files instead of copying them. While the code includes checks
against symbolic links in the source repository, which were added during the fix
for CVE-2022-39253, these checks can still be raced because the hard link
operation ultimately follows symlinks. If the object on the filesystem appears as
a file during the check, and then a symlink during the operation, this will allow
the adversary to bypass the check and create hardlinks in the destination objects
directory to arbitrary, user-readable files. The problem has been patched in
versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.
CVE-2024-32465:
Git is a revision control system. The Git project recommends to avoid working in
untrusted repositories, and instead to clone it first with `git clone --no-local`
to obtain a clean copy. Git has specific protections to make that a safe
operation even with an untrusted source repository, but vulnerabilities allow
those protections to be bypassed. In the context of cloning local repositories
owned by other users, this vulnerability has been covered in CVE-2024-32004. But
there are circumstances where the fixes for CVE-2024-32004 are not enough: For
example, when obtaining a `.zip` file containing a full copy of a Git repository,
it should not be trusted by default to be safe, as e.g. hooks could be configured
to run within the context of that repository. The problem has been patched in
versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a
workaround, avoid using Git in repositories that have been obtained via archives
from untrusted sources.
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-32002https://nvd.nist.gov/vuln/detail/CVE-2024-32004https://nvd.nist.gov/vuln/detail/CVE-2024-32020https://nvd.nist.gov/vuln/detail/CVE-2024-32021https://nvd.nist.gov/vuln/detail/CVE-2024-32465
(From OE-Core rev: 209c41377abf6853455b00af3923f1b244a3766b)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2024-24576 only applies when invoking batch files (with the `bat` and `cmd` extensions) on Windows & No other platform or use is affected.
More details about CVE is here: https://nvd.nist.gov/vuln/detail/CVE-2024-24576
(From OE-Core rev: 44e0b6b028657d32de5971d6a42a88767ef8c710)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
These test suites are full of timing-sensitive test cases, so skip
them too.
[ YOCTO #15321 ]
(From OE-Core rev: f94c74cee8b2650dd3211a49dc7e88bf60d2e6a7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dd06c3668dbe9ec1cf9a0a84d7a6bc9851f9c662)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
There are several tests in the test suite which are very dependent on
timing and fail on a loaded host system, so skip them.
[ YOCTO #14825#14882#15081 ]
(From OE-Core rev: 161d336a6c57fddb36a0c4e8c2def84ce70128e3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 68beb4f4b5a0bea5d431decddf7656f18ac7a04a)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Some tests hardcode assumptions on locales, which may not be present in
musl systems e.g., therefore add a way to skip such tests using -skip
option.
Skip unixInit-3* test on musl
(From OE-Core rev: a70f9039259d7d38c5a3e50f7003d3228d1ab692)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit fa66f1cee2d88c2276442e8b4aaeccde5490f9ea)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2023-47100 is a duplicate of CVE-2023-47038. They have the same
advertised fix commit, which has already been merged into the
perl_5.34.3 sources used in kirkstone.
(From OE-Core rev: 8df158f39f1eed1e3ae88ddf935c67e067b72525)
Signed-off-by: Alex Stewart <alex.stewart@ni.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When using the gcc-sanitizers as part of the SDK on a Linux with a newer
kernel, the ASAN fails randomly. This was seen on Ubuntu 22.04.
This is also described at
https://stackoverflow.com/questions/77894856/possible-bug-in-gcc-sanitizers
Backport the fix from LLVM project, as gcc has not yet backported
anything for the 11 series.
(From OE-Core rev: 7af8e24d6c60a01e398b10a57939947fb156feec)
Signed-off-by: Claus Stovgaard <claus.stovgaard@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
https://github.com/urllib3/urllib3/releases/tag/1.26.18
Major changes in python3-urllib3 1.26.18:
- Made body stripped from HTTP requests changing the request method to GET after HTTP 303 "See Other" redirect responses. (CVE-2023-45803)
(cherry picked from OE-Core rev: 74da05b63634c248910594456dae286947f33da5)
(From OE-Core rev: c473f32184ea0ab41f6eb4c8dcc1d7bb5fd7b16f)
Signed-off-by: Tan Wen Yan <wen.yan.tan@intel.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
1. scsi-disk: allow MODE SELECT block descriptor to set the block size
Link: 356c4c441e
The MODE SELECT command can contain an optional block descriptor that can be used
to set the device block size. If the block descriptor is present then update the
block size on the SCSI device accordingly.
This allows CDROMs to be used with A/UX which requires a CDROM drive which is
capable of switching from a 2048 byte sector size to a 512 byte sector size.
2. scsi-disk: ensure block size is non-zero and changes limited to bits 8-15
Link: 55794c904d
The existing code assumes that the block size can be generated from p[1] << 8
in multiple places which ignores the top and bottom 8 bits. If the block size
is allowed to be set to an arbitrary value then this causes a mismatch
between the value written by the guest in the block descriptor and the value
subsequently read back using READ CAPACITY causing the guest to generate
requests that can crash QEMU.
For now restrict block size changes to bits 8-15 and also ignore requests to
set the block size to 0 which causes the SCSI emulation to crash in at least
one place with a divide by zero error.
3. Disallow block sizes smaller than 512 [CVE-2023-42467]
Link: 7cfcc79b0a
We are doing things like
nb_sectors /= (s->qdev.blocksize / BDRV_SECTOR_SIZE);
in the code here (e.g. in scsi_disk_emulate_mode_sense()), so if
the blocksize is smaller than BDRV_SECTOR_SIZE (=512), this crashes
with a division by 0 exception. Thus disallow block sizes of 256
bytes to avoid this situation.
(From OE-Core rev: e9af3d328db8a32c22bb0798fa8dbb749e3f607b)
Signed-off-by: Poonam Jadhav <poonam.jadhav@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
As discussion in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for recipes
using cmake.
The variable CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES value updates incorrectly
during do_compile the code. Due to this getting sporadic error like below,
fatal error: stdlib.h: No such file or directory
| 75 | #include_next <stdlib.h>
| | ^~~~~~~~~~
| compilation terminated.
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.
As cmake already correctly initializes the variable from environment,
So we have to unset it in the toolchain file to avoid overwriting the
variable definition again.
(From OE-Core rev: 2b0b47fd0cafdb9de5025efda4140e11ea447afa)
Signed-off-by: aszh07 <mail2szahir@gmail.com>
Signed-off-by: Zahir Hussain <zahir.basha@kpit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5aeada5793af53e8c93940952d4f314474dca4c2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The original CVE-2023-29406.patch is not complete, causing docker
failures at runtime, backport a complementary fix from golang upstream.
(From OE-Core rev: 973901530c98bc3f1b10d8bb89d55decf6848713)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2023-45285:
Using go get to fetch a module with the ".git" suffix may unexpectedly
fallback to the insecure "git://" protocol if the module is unavailable
via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE
is not set for said module. This only affects users who are not using
the module proxy and are fetching modules directly (i.e. GOPROXY=off).
CVE-2023-45287:
Before Go 1.20, the RSA based TLS key exchanges used the math/big
library, which is not constant time. RSA blinding was applied to prevent
timing attacks, but analysis shows this may not have been fully effective.
In particular it appears as if the removal of PKCS#1 padding may leak
timing information, which in turn could be used to recover session key
bits. In Go 1.20, the crypto/tls library switched to a fully constant
time RSA implementation, which we do not believe exhibits any timing
side channels.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45285https://nvd.nist.gov/vuln/detail/CVE-2023-45287https://security-tracker.debian.org/tracker/CVE-2023-45285https://security-tracker.debian.org/tracker/CVE-2023-45287
(From OE-Core rev: 616857b9918e8d2e576239b3db2f9f077d1a7222)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Concept of gcc-source prevents cve-check to detect existing
CVE patch file.
So ignore this CVE in all recipes using gcc-source via this
include file.
(From OE-Core rev: 04511734c6dc8c7dda3a943b385cd273d012d8c7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Changelog:
==========
-Fix compiler error when checking if required blocks in parent templates are empty.
-xmlattr filter does not allow keys with spaces.
-Make error messages stemming from invalid nesting of {% trans %} blocks more helpful
(cherry picked from OE-Core rev: 8a0524464583d69df7746253f5020c2c125a8e1f)
(From OE-Core rev: 0f0dcf520505d809599a63961ecb5b1e74053b24)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Some distributions shipping gcc12 end up with stringop-overflow warnings
e.g.
/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ specified size between 9223372036854775813 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
74 | return __glibc_fortify (pread, __nbytes, sizeof (char),
| ^~~~~~~~~~~~~~~
Until fixed, lets not treat this warning as hard error
MJ: this is needed e.g. on ubuntu 24.04 after gcc was upgraded
from 13.2.0-8ubuntu1 to 13.2.0-9ubuntu1 which includes
switch _FORTIFY_SOURCE to 3:
https://changelogs.ubuntu.com/changelogs/pool/main/g/gcc-13/gcc-13_13.2.0-9ubuntu1/changelog
elfutils config.log then shows:
configure:6762: checking whether to add -D_FORTIFY_SOURCE=2 to CFLAGS
configure:6779: gcc -c -D_FORTIFY_SOURCE=2 -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include -O2 -pipe -Werror -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include conftest.c >&5
<command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
configure:6786: result: no
and -D_FORTIFY_SOURCE=2 missing in CFLAGS later causes the above error
in do_compile
(From OE-Core rev: 94d1640d374c9a8827957cba8dbc1c1f978701b5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
