Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7,
2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, by feeding
specially crafted input to `git apply --reject`, a path outside the working
tree can be overwritten with partially controlled contents (corresponding to
the rejected hunk(s) from the given patch). A fix is available in versions
2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3,
and 2.40.1. As a workaround, avoid using `git apply` with `--reject` when applying
patches from an untrusted source. Use `git apply --stat` to inspect a patch before
applying; avoid applying one that create a conflict where a link corresponding to
the `*.rej` file exists.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-25652
Upstream-Status: Backport from 9db05711c9
(From OE-Core rev: 6747482316b8f7839a09bf041d8c11b559f84b44)
Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8,
2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, a specially crafted
`.gitmodules` file with submodule URLs that are longer than 1024 characters can used
to exploit a bug in `config.c::git_config_copy_or_rename_section_in_file()`. This bug
can be used to inject arbitrary configuration into a user's `$GIT_DIR/config` when
attempting to remove the configuration section associated with that submodule. When the
attacker injects configuration values which specify executables to run (such as
`core.pager`, `core.editor`, `core.sshCommand`, etc.) this can lead to a remote code
execution. A fix A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8,
2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid running
`git submodule deinit` on untrusted repositories or without prior inspection of any
submodule sections in `$GIT_DIR/config`.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29007
Upstream patches:
528290f8c629198213c9a5bb10fd5ee91cfe60853bb3d6bac5
(From OE-Core rev: db4c152441aebe4c04a7bb7aceb88d8941a6576b)
Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If a package with a postsints script requires ldconfig, the package class adds
a ldconfig postinst fragment to initialize it before. Systemd has its own
ldconfig.service to initialize it and sometimes if both services are running
at the same time in the first boot, the first one will work, but the second
one will fail with the following error:
ldconfig[141]: /sbin/ldconfig: Renaming of /etc/ld.so.cache~ to /etc/ld.so.cache failed: No such file or directory
This commit adds a ordering dependency between them to make sure that only one
service is running at the same time.
(From OE-Core rev: 1bc254e7969f3d5470bacf9ad9f065d38b7b7fde)
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4e9d812e127dc6743f52f4881e509e8e2e833afe)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.
The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.
Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
Fixes CVE-2023-24534
For #58975Fixes#59267
(From OE-Core rev: daa6aa9c7198a07322f1828a9db457fec86191cf)
Signed-off-by: Vivek Kumbhar <vkumbhar@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Setting a large line or column number using a //line directive can cause
integer overflow even in small source files.
Limit line and column numbers in //line directives to 2^30-1, which
is small enough to avoid int32 overflow on all reasonbly-sized files.
(From OE-Core rev: d1943e6a0ec00653c81cd4c0bb0d6b7e0909094c)
Signed-off-by: Vivek Kumbhar <vkumbhar@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
encoding/xml: replace comments inside directives with a space
Backport from a9cfd55e2b
(From OE-Core rev: 76d855f3d2c250ac85ca6f24bf0e178fb32607f9)
Signed-off-by: Shubham Kulkarni <skulkarni@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This CVE is specific to Microsoft Windows, ignore it.
Patch fixing it (https://go-review.googlesource.com/c/go/+/446916)
also adds a redundant check to generic os/exec which
could be backported but it should not be necessary as
backport always takes a small risk to break old code.
(From OE-Core rev: 4263f3fda59aacb4f159d2dffb52e5f66249b5e4)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
path/filepath: do not Clean("a/../c:/b") into c:\b on Windows
Backport from bdf07c2e16
(From OE-Core rev: 70135bf04eb7173434a7240ddf11639d13aab003)
Signed-off-by: Shubham Kulkarni <skulkarni@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The patch for CVE-2021-3929 applied on dunfell returns a value for a
void function. This results in the following compiler warning/error:
hw/block/nvme.c:77:6: error: void function
'nvme_addr_read' should not return a value [-Wreturn-type]
return NVME_DATA_TRAS_ERROR;
^ ~~~~~~~~~~~~~~~~~~~~
In newer versions of qemu, the functions is changed to have a return
value, but that is not present in the version of qemu used in “dunfell”.
Backport some of the patches to correct this.
(From OE-Core rev: 4ad98f0b27615ad59ae61110657cf69004c61ef4)
Signed-off-by: Gaurav Gupta <gauragup@cisco.com>
Signed-off-by: Gaurav Gupta <gauragup@cisco.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.
Backport from 5c3e11bd0b
(From OE-Core rev: 53a303fb5908edaf29e35abb08fff93e7c0ff92c)
Signed-off-by: Shubham Kulkarni <skulkarni@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
import patches from ubuntu to fix
CVE-2020-15469
CVE-2020-15859
CVE-2020-17380
CVE-2020-35504
CVE-2020-35505
CVE-2021-3409
CVE-2022-26354
https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/patches?h=ubuntu/focal-security
Combine patches for both CVE-2020-25085 and CVE-2021-3409 also fix CVE-2020-17380.
so mark CVE-2020-17380 fixed by CVE-2021-3409 patches. CVE-2020-17380 patch backported since
oecore rev 6b4c58a31ec11e557d40c31f2532985dd53e61eb.
(From OE-Core rev: 3ee2e9027d57dd5ae9f8795436c1acd18a9f1e24)
Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport of gcc upstream commit 2b2d97fc545635a0f6aa9c9ee3b017394bc494bf
to gcc release 9.5.0. This fix is available to all release-branches
except releases/gcc-9 because upstream do not support gcc-9 now.
(From OE-Core rev: 9779b66162a014f26594bdde43afdc4332617240)
Signed-off-by: Virendra Thakur <virendrak@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test assumes that if a child process writes one line to stderr and
then another line to stdout, and stderr is redirected to stdout, that
the order the lines will be read is stable.
This isn't the case and occasionally the lines will be read in a
different order. Change the test to ignore line ordering.
[ YOCTO #14469 ]
(From OE-Core rev: 2c9fe8c3bb1cc1883c7bd445d019b2107e85ab2b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1ddbe4d2bd8d8da10dac8a054f130fcd1d242219)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a PACKAGECONFIG option for slirp, defaulting to internal. This avoids
the presence of libslirp on the host causing qemu to link against that
instead breaking reproducibility and usability of the binary on hosts
where the library isn't present.
We need to add it to PACKAGECONFIG by default since users do expect slirp
to be enabled in the wider community.
Note: qemu version 4.2.0 doesn't support an "internal" option for
enable-slirp, so use "git" instead which uses the same configure
code path, avoids host libslirp contamination and forces use of the
qemu internal slirp implementation.
(From OE-Core rev: e5dc03e4a3b71ff144896a8ce56a34b8677e8e27)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5a9a64132bf5ecac9d611d29751226a466c4a2c1)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default GOCACHE is set to $HOME/.cache.
Same issue for all other go recipes had been fixed by commit 9a6d208b:
[ go: avoid host contamination by GOCACHE ]
but that commit missed go-crosssdk recipe.
(From OE-Core rev: 22fef4e278beae60d1a6afbe4645fb36732bc736)
Signed-off-by: Robert Andersson <robert.m.andersson@atlascopco.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit e5fd10c647ac4baad65f9efa964c3380aad7dd10)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Distros can customize the location of OPKG data using OPKGLIBDIR. In
OE-Core commit 11f1956cf5d7 ("package_manager.py: define info_dir and
status_file when OPKGLIBDIR isn't the default"), a fix was applied to
correctly set the info_dir and status_file options relative to
OPKGLIBDIR.
However, as the commit message notes, the opkg.conf file deployed as
part of the opkg package must also be adjusted to correctly reflect the
changed location. Otherwise, opkg running inside the image cannot find
its data.
Fix this by also setting the info_dir and status_file options in
opkg.conf to the correct location relative to OPKGLIBDIR.
Fixes: 11f1956cf5d7 ("package_manager.py: define info_dir and status_file when OPKGLIBDIR isn't the default")
(From OE-Core rev: 38224b19bda2592705ef4274c28cb250d9e980dc)
Signed-off-by: Harald Seiler <hws@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit adb939ae3635de6e02208859fbf29cf0ed39f565)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE is in the io/fs package, which first appeared in go1.16.
Since dunfell is using go1.14, this issue does not apply.
CVE was fixed in fa2d41d0ca736f3ad6b200b2a4e134364e9acc59
Original code in b64202bc29b9c1cf0118878d1c0acc9cdb2308f6
(From OE-Core rev: 1e258940e9a6fabda6e7e60841082c113fdf9500)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only affects Windows platform, as per the release announcement [1]:
"If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
are executed when Cmd.Path is unset and, in the working directory, there
are binaries named either "..com" or "..exe", they will be executed."
[1] https://groups.google.com/g/golang-announce/c/TzIC9-t8Ytg/m/IWz5T6x7AAAJ
(From OE-Core rev: 54c40730bc54aa2b2c12b37decbcc99bbcafd07a)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dunfell uses golang 1.14 which does not contain the affected code (it
was introduced in golang 1.16). From the golang announcement [1]
"Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can
be made to panic by an attacker providing either a crafted ZIP archive
containing completely invalid names or an empty filename argument.
[1] https://groups.google.com/g/golang-announce/c/0fM21h43arc
(From OE-Core rev: 2329902f994b631d6b77e8bd501d5599db6d5306)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a bug in golang.org/x/net/html/parse.go. The golang compiler
includes a partial copy of this under src/vendor/golang.org/x/net/
however the "html" subdirectory is not included. So this bug does not
apply to the compiler itself.
(From OE-Core rev: b8a851faef9990ccb41ded875fc79cf28abd4a4e)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
