The error is misleading: it reports that no name was provided,
when in fact the external.desc file is missing.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>p
Reviewed-by: Romain Naour <romain.naour@gmail.com>
(cherry picked from commit c62e78a85b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a br2-external tree has an issue, e.g. a missing file, or does not
have a name, or the name uses invalid chars, we report that condition by
setting the variable BR2_EXTERNAL_ERROR.
That variable is defined in the script support/scripts/br2-external,
which outputs it on stdout, and checked by the Makefile.
Before d027cd75d0, stdout was explicitly redirected to the generated
.mk file, with exec >"${ofile}" as the Makefile and Kconfig
fragments were generated each with their own call to the script, and
the validation phase would emit the BR2_EXTERNAL_ERROR variable in the
Makefile fragment.
But with d027cd75d0, both the Makefile and Kconfig fragments were now
generated with a single call to the script, and as such the semantics of
the scripts changed, and only each of the actual generators, do_mk and
do_kconfig, had their out put redirected. Which left do_validate with
the default stdout. Which would emit BR2_EXTERNAL_ERROR on stdout.
In turn, the stdout of the script would be interpreted by as part of the
Makefile. But this does not end up very well when a br2-external tree
indeed has an error:
- missing a external.desc file:
Makefile:184: *** multiple target patterns. Stop.
- empty external.desc file:
Config.in:22: can't open file "output/.br2-external.in.paths"
So we must redirect the output of the validation step to the
Makefile fragment, so that the error message is correctly caught by the
top-level Makefile.
Note that we don't need to append in do_mk, and we can do an overwrite
redirection: if we go so far as to call do_mk, it means there was no
error, and thus the fragment is empty.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
(cherry picked from commit 0ac7dcb73e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-12049: An issue was discovered in dbus >= 1.3.0 before
1.12.18. The DBusServer in libdbus, as used in dbus-daemon, leaks file
descriptors when a message exceeds the per-message file descriptor
limit. A local attacker with access to the D-Bus system bus or another
system service's private AF_UNIX socket could use this to make the
system service reach its file descriptor limit, denying service to
subsequent D-Bus clients.
- Also update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 7cee9d2659)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A gcc compiler, which was configured with
--with-gcc-major-version-only, will only return a single
number. (debian does this for example).
A simple modification allows the check to work with both
single numbers (eg. '9') and full versions (eg. '9.2.1').
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5303e72a80)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since cf75d7da98 we have a build failures when
building libgbm.so when valgrind package is selected because --static is always
passed to pkg-config even for shared build.
Even if -Dvalgrind=false on meson command line to build mesa, the valgrind
libraries come from pkg-config libdrm...
output/host/bin/pkg-config libdrm --libs --static
-L[...]/sysroot/usr/lib -ldrm -lm -L[...]/sysroot/usr/lib/valgrind
-lcoregrind-arm64-linux -lvex-arm64-linux -lgcc
... and break the build.
See initial discussions:
http://lists.busybox.net/pipermail/buildroot/2020-June/284543.html
This is due to a wrong condition test added by the patch
0004-mesonbuild-dependencies-base.py-add-pkg_config_stati.patch.
Indeed, pkg_config_static is a string, not a boolean; it is set to
either 'true' or 'aflse' by our meson package infra. Since the returned
object is a string, do not pass a boolean, but pas None (we only want to
test against the 'true' string, so we don't care what we get back when
it is not set, which never happens in Buildroot).
Before this patch, the issue can be reproduced using the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_VALGRIND=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
Fixes:
http://autobuild.buildroot.net/results/1b5/1b58d73ecbbe1af2c3e140563d696cf32d1c4a5a/build-end.log
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: slightly reword the commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 6ae1932e71)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes (on startup):
$ usr/libexec/iwd
Wireless daemon version 1.7
Failed to initialize D-Bus
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[yann.morin.1998@free.fr:
- move MMU dependency first
- split long line in comment dependencies
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 6f5f6bcd89)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Meson build system enable by default -Wl,--as-needed [1][2] in the linker command line
and due to this the libmesa_dri_drivers.so build fail with the Codesourcery ARM and
Aarch64 2014.05 toolchain:
/home/buildroot/autobuild/run/instance-1/output-1/host/bin/arm-none-linux-gnueabi-g++
-o src/mesa/drivers/dri/libmesa_dri_drivers.so
-Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group
-Wl,-soname,libmesa_dri_drivers.so -Wl,--whole-archive
src/mesa/drivers/dri/radeon/libr100.a src/mesa/drivers/dri/nouveau/libnouveau_vieux.a
-Wl,--no-whole-archive
src/mesa/drivers/dri/common/libmegadriver_stub.a
src/mesa/drivers/dri/common/libdricommon.a
src/mapi/shared-glapi/libglapi.so.0.0.0
src/mesa/libmesa_classic.a src/mesa/libmesa_common.a
src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a
src/util/libmesa_util.a src/util/format/libmesa_format.a
src/compiler/nir/libnir.a src/compiler/libcompiler.a
src/util/libxmlconfig.a
[...]
src/mesa/drivers/dri/common/libmegadriver_stub.a(megadriver_stub.c.o): In function `megadriver_stub_init':
megadriver_stub.c:(.text.startup+0x20): undefined reference to `dladdr'
megadriver_stub.c:(.text.startup+0xbc): undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
This problem seems to be specific to this toolchain release (ARM and aarch64)
CodeSourcery 2014.05: gcc 4.8.3-prerelease; binutils 2.24.51.20140217; glibc 2.18
The following prebuilt toolchain has been tested and doesn't trigger this issue:
Linaro 4.9-4.9-2014.11: gcc 4.9.3; binutils 2.24.0; glibc 2.19
CodeSourcery 2014.11: gcc 4.9.1; binutils 2.24.51.20140217; glibc 2.20
Older toolchains doesn't have a recent enough glibc or linux-headers version
to breaking the build with mesa3d 20.1.0 or libdrm 2.4.102.
In order to build mesa3d with the CodeSourcery 2014.05 using --as-needed would be
reorder the static librairies:
diff --git a/src/mesa/drivers/dri/meson.build b/src/mesa/drivers/dri/meson.build
index b09ca16e38a..9ac6731c522 100644
--- a/src/mesa/drivers/dri/meson.build
+++ b/src/mesa/drivers/dri/meson.build
@@ -59,7 +59,7 @@ if _dri_drivers != []
[],
link_whole : _dri_drivers,
link_with : [
- libmegadriver_stub, libdricommon, libglapi,
+ libdricommon, libmegadriver_stub, libglapi,
libmesa_classic,
],
Instead, we can disable --as-needed from the meson build system using
"-Db_asneeded=false" only for this toolchain.
[1] https://mesonbuild.com/Builtin-options.html
[2] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed
Fixes:
http://autobuild.buildroot.net/results/eec39a4fbfbfaa58980fab36f2fd902a16eecf0f/build-end.log
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit d3f576d2f3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2020-11080 Denial of service: Overly large SETTINGS frames
Signed-off-by: Martin Bark <martin@barkynet.com>
[yann.morin.1998@free.fr: two spaces in hash files]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e500367ea4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a security release.
Vulnerabilities fixed:
CVE-2020-8172: TLS session reuse can lead to host certificate verification bypass (High).
CVE-2020-11080: HTTP/2 Large Settings Frame DoS (Low).
CVE-2020-8174: napi_get_value_string_*() allows various kinds of memory corruption (High).
See https://nodejs.org/en/blog/release/v12.18.0/
Signed-off-by: Martin Bark <martin@barkynet.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 06decad41b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Install header files and libraries into the staging area. Some
packages like mraa (if enabled for Node.js) search for node.h
and v8.h. Hence, Node.js development file must be installed to
the staging area.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f6e6e648ce)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2020-13401: Disable IPv6 Router Advertisements to prevent address
spoofing
An attacker in a container, with the CAP_NET_RAW capability, can craft
IPv6 router advertisements, and consequently spoof external IPv6 hosts,
obtain sensitive information, or cause a denial of service.
In addition, 19.03.9..11 fixes a number of issues. For details, see:
https://docs.docker.com/engine/release-notes/
Signed-off-by: Christian Stewart <christian@paral.in>
[Peter: mention security impact, extend commit message]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b73b3835f4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.13.9 (released 2020/03/19) includes fixes to the go command, tools, the
runtime, the toolchain, and the crypto/cypher package.
go1.13.10 (released 2020/04/08) includes fixes to the go command, the runtime,
and the os/exec and time packages.
go1.13.11 (released 2020/05/14) includes fixes to the compiler.
go1.13.12 (released 2020/06/01) includes fixes to the runtime, and the go/types
and math/big packages.
Release notes: https://golang.org/doc/go1.13
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 7cbb3dd94e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The D-Bus installation process installs dbus-daemon-launch-helper as
follows:
chown root:$(DBUS_USER) $(DESTDIR)$(libexecdir)/dbus-daemon-launch-helper$(EXEEXT); \
chmod 4750 $(DESTDIR)$(libexecdir)/dbus-daemon-launch-helper$(EXEEXT); \
And when the installation does not take place as root (like is the
case in the context of Buildroot), it prints:
echo "Not installing $(DESTDIR)$(libexecdir)/dbus-daemon-launch-helper binary setuid!"; \
echo "You'll need to manually set permissions to root:$(DBUS_USER) and permissions 4750"; \
So let's adjust the installation logic of dbus-daemon-launch-helper to
match these requirements.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 7ac245a0cb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 54ea03ccd7 ("package/syslog-ng:
implement systemd enablement using DefaultInstance") replaced the lines
installing the syslog-ng@default file with printf lines creating a file
in a syslog-ng@.service.d/ directory on-the-fly. Since then, nothing
uses the syslog-ng@default file, so let's delete it.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2a473a9f05)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The configure script will automatically detect used pkg-config if
libcap or libselinux are available.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1b9f6fd039)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Switch site to github to get latest release
- Fix CVE-2019-20805: p_lx_elf.cpp in UPX before 3.96 has an integer
overflow during unpacking via crafted values in a PT_DYNAMIC segment.
- Fix CERT-FI Case 829767 UPX command line tools segfaults.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 0f57837f6a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It is often necessary to refer to other images that are present in
BINARIES_DIR from a custom ubinize configuration e.g. to include the
kernel in a UBI volume.
As we do for BR2_ROOTFS_UBIFS_PATH, replace BINARIES_DIR when copying
the file.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
[yann.morin.1998@free.fr:
- add the blurb in the help text
- rewrap commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 145ee99bc9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes a critical issue related to streams. From the release notes:
================================================================================
Redis 5.0.9 Released Thu Apr 17 12:41:00 CET 2020
================================================================================
Upgrade urgency:CRITICAL if you use Streams with AOF ore replicas.
Otherwise the upgrade urgency is LOW.
This release has a speed improvement and a critical fix:
* FIX: XREADGROUP when fetching data in a blocking way, would not
emit the XCLAIM in the AOF file and to replicas. This means
that the last ID is not updated, and that restarting the server
will have the effect of reprocessing some entries.
* NEW: Clients blocked on the same key are now unblocked on
O(1) time. Backported from Redis 6.
Commits:
1fc8ef81a Fix XCLAIM propagation in AOF/replicas for blocking XREADGROUP.
a5e24eabc Speedup: unblock clients on keys in O(1).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Backport a patch from upstream to fix the build on certain versions of
gsc, notably:
Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
The upstream patch is simply a change in the gentpl.py script, which is
used to generate parts of the automake machinery, so if we just backport
the upstream patch, we need to call the script to regenerate those files.
However, the modified script is a python script, so we would need to add
a dependency on host-python (2 or 3), which is not so nice.
Furthermore, calling the script is not enough: it needs a specific set
of optionss for each file it is to generate. That set of options is not
static; it is constructed in the convoluted autogen.sh. Calling
autogen.sh is usally not so good an idea in the Buildroot context, and
indeed this fails becasue it calls to autoreconf, but without our
carefuly crafted options and environment variables.
There was a little light in the tunnel, in that autogen.sh can be told
not to run autoreconf, by setting the environemnt variable
FROM_BOOTSTRAP to an non-=empty string, but this is fraught with various
other side-effects, as in that cause, autogen.sh expects to be valled by
an upper sciopt, bootstrap, which is not provided in the tarball
distribution...
So, between all those issues, autogen, bootstrap, and a host-python (2
or 3) dependency, we choose another route: path the script *and* the one
generated file affected by the change. Since that patched file is a .am
file, we also patch the corresponding .in file
However, we're faced with another issue: the other generated file is
now older than the script, so the automake machinery will now want to
re-run autoconf et al during the build step, which is still not a good
idea for us. So we touch the other generated file so it is mopre recent
than the script.
This is still not sufficient, because the patched file also has a
dependency on the generated file, so we need to touch as well.
Fixes:
- https://bugs.buildroot.org/show_bug.cgi?id=12946
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- keep the hunk about patching gentpl.py
- make it a git-formatted patch
- add the touch
- drastically expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 7e64a050fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit fa84c176c2 that
replace luabitop by lua_bit32 package when lua 5.1 is used.
Since this change the prosody test in gitlab is fail due to
missing lua-bitops [1]:
Starting prosody:
**************************
Prosody was unable to find lua-bitops
This package can be obtained in the following ways:
Source: http://bitop.luajit.org/
Debian/Ubuntu: sudo apt-get install lua-bitop
luarocks: luarocks install luabitop
WebSocket support will not be available
More help can be found on our website, at https://prosody.im/doc/depends
**************************
The upstream documentation [2] is misleading (or not uptodate)
about lua-bit32 dependency.
Since bitop is builtin since lua5.2, we probably need to select
luabitop package only when lua 5.1 is used as lua interpreter.
Tested with run-tests:
./support/testing/run-tests tests.package.test_prosody.TestProsodyLua51
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/576271975
[2] https://prosody.im/doc/depends#bitop
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit cf810e4099)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-13645: In GNOME glib-networking through 2.64.2, the
implementation of GTlsClientConnection skips hostname verification of
the server's TLS certificate if the application fails to specify the
expected server identity. This is in contrast to its intended
documented behavior, to fail the certificate verification.
Applications that fail to provide the server identity, including Balsa
before 2.5.11 and 2.6.x before 2.6.1, accept a TLS certificate if the
certificate is valid for any host.
- Update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: bump to 2.62.4 rather than 2.64.3]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8f3d361f5c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
LIBUSB_1_0_SONAME is detected since version 0.1.6 and
b6f5a2fe12
The detection mechanism is based on sed, here are the more relevant
parts:
shrext_regexp=`echo "$shrext_cmds" | sed 's/\./\\\\./'`
[...]
[AS_VAR_SET([ac_Lib_SONAME], [`ldd conftest$ac_exeext | grep 'lib[$2]'$shrext_regexp | sed 's/^@<:@ \t@:>@*lib[$2]'$shrext_regexp'/lib[$2]'$shrext_regexp'/;s/@<:@ \t@:>@.*$//'`])])
However, this mechanism is broken with sed 4.7 and will return the
following 'silent' error:
checking for SONAME of libusb-1.0... sed: -e expression #1, char 40: Invalid back reference
unknown
Moreover, it also raises the following build failure on one of the
autobuilder because an empty line is added to LIBUSB_1_0_SONAME:
checking for SONAME of libusb-1.0... checking
libusb-1.0.so.0
checking for GNU extensions of errno.h... no
configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libusb.pc
config.status: creating libusb-config
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating examples/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls
configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline
[7m>>> libusb-compat 0.1.7 Building[27m
PATH="/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/bin:/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/sbin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1
/usr/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin" /usr/bin/make -j8 -C /usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7/
make[1]: Entering directory `/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7'
Makefile:284: *** missing separator. Stop.
We could patch patch m4/au_check_lib_soname.m4 to fix the mechanism
however this is difficult without reproducing the autobuilder failure
and upstream seems dead so just set LIBUSB_1_0_SONAME
Fixes:
- http://autobuild.buildroot.org/results/12d771d85d30594929cfe3e1c783fc70857e7f5f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: extract the actual SONAME from the library]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 3a9261ddd9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the linux-headers are configured to use the same source as the
kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured
to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION
or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the
kernel sources are not already downloaded:
$ cat defconfig
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y
$ make defconfig BR2_DEFCONFIG=$pwd)/defconfig
$ make linux-headers-source
>>> linux-headers 4.19.118-cip25 Downloading
--2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176
Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-05-13 19:28:45 ERROR 404: Not Found.
make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1
make: *** [Makefile:23: _all] Error 2
We fix that by adding yet another duplication of information out of
the linux.mk, to use the CIP-specific git tree where to get the
archives as snapshots.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d25a5724c0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The current script (S51sysrepo-plugind) is not able to stop the daemon.
Possible options to fix the problem:
A) By adding the "-m -p $PIDFILE" option to start the pid file will be
created but it will not contain the correct PID used by the daemon.
This is obviously because the daemon forks.
B) By not starting the daemon in background (sysrepo-plugind -d) and
let do it by start-stop-daemon with "-b" option. But then the log
messages of the daemon will not longer ends in the syslog but to stderr.
C) Start the daemon without a pidfile and stop the daemon with the
"-x" option.
The only valid option is C to fix that.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[yann.morin.1998@free.fr: introduce EXECUTABLE]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1a14a838ea)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service or possibly gain
privileges because of missing memory barriers in read-write unlock
paths. The read-write unlock paths don't contain a memory barrier. On
Arm, this means a processor is allowed to re-order the memory access
with the preceding ones. In other words, the unlock may be seen by
another processor before all the memory accesses within the "critical"
section. As a consequence, it may be possible to have a writer executing
a critical section at the same time as readers or another writer. In
other words, many of the assumptions (e.g., a variable cannot be
modified after a check) in the critical sections are not safe anymore.
The read-write locks are used in hypercalls (such as grant-table ones),
so a malicious guest could exploit the race. For instance, there is a
small window where Xen can leak memory if XENMAPSPACE_grant_table is
used concurrently. A malicious guest may be able to leak memory, or
cause a hypervisor crash resulting in a Denial of Service (DoS).
Information leak and privilege escalation cannot be excluded.
- Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (without active profiling) to obtain
sensitive information about other guests. Unprivileged guests can
request to map xenoprof buffers, even if profiling has not been enabled
for those guests. These buffers were not scrubbed.
- Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (with active profiling) to obtain
sensitive information about other guests, cause a denial of service, or
possibly gain privileges. For guests for which "active" profiling was
enabled by the administrator, the xenoprof code uses the standard Xen
shared ring structure. Unfortunately, this code did not treat the guest
as a potential adversary: it trusts the guest not to modify buffer size
information or modify head / tail pointers in unexpected ways. This can
crash the host (DoS). Privilege escalation cannot be ruled out.
- Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of bad
continuation handling in GNTTABOP_copy. Grant table operations are
expected to return 0 for success, and a negative number for errors. The
fix for CVE-2017-12135 introduced a path through grant copy handling
where success may be returned to the caller without any action taken. In
particular, the status fields of individual operations are left
uninitialised, and may result in errant behaviour in the caller of
GNTTABOP_copy. A buggy or malicious guest can construct its grant table
in such a way that, when a backend domain tries to copy a grant, it hits
the incorrect exit path. This returns success to the caller without
doing anything, which may cause crashes or other incorrect behaviour.
- Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of a bad
error path in GNTTABOP_map_grant. Grant table operations are expected to
return 0 for success, and a negative number for errors. Some misplaced
brackets cause one error path to return 1 instead of a negative value.
The grant table code in Linux treats this condition as success, and
proceeds with incorrectly initialised state. A buggy or malicious guest
can construct its grant table in such a way that, when a backend domain
tries to map a grant, it hits the incorrect error path. This will crash
a Linux based dom0 or backend domain.
https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 0caabc8cda)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The commit [1] "licensing info is only valid for v1.4" fixed the legal-info
issues when a custom ATF tarball or a version from git is used.
But we need to ignore licencing for a used defined official ATF version.
Althougt the ATF version are licensed under BSD-3-Clause, the license
file can be updated between version (for example between v1.4 and v2.0).
Ignore the licencing check if the user provide a custom official version.
[1] d1a61703f7
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: use positive logic with the _LATEST option]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 36c0a0c656)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that Freescale has been wholly swallowed into NXP, the public-facing
git repositories that were hosting those two packages are no longer
available.
Fortunately, they had been mirrored on Code Aurora forge (a Linux
Foundation project, so relatively stable and trustworthy), which has the
tags we need, and that generates the exact same archives.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 3bfe849189)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Switch site to an active fork
- Send patch upstream
- Update indentation in hash file (two spaces)
- Fix the following CVEs:
- CVE-2018-14054: A double free exists in the MP4StringProperty class
in mp4property.cpp in MP4v2 2.0.0. A dangling pointer is freed again
in the destructor once an exception is triggered.
Fixed by
f09cceeee5
- CVE-2018-14325: In MP4v2 2.0.0, there is an integer underflow (with
resultant memory corruption) when parsing MP4Atom in mp4atom.cpp.
Fixed by
e475013c6e
- CVE-2018-14326: In MP4v2 2.0.0, there is an integer overflow (with
resultant memory corruption) when resizing MP4Array for the ftyp
atom in mp4array.h.
Fixed by
70d823ccd8
- CVE-2018-14379: MP4Atom::factory in mp4atom.cpp in MP4v2 2.0.0
incorrectly uses the MP4ItemAtom data type in a certain case where
MP4DataAtom is required, which allows remote attackers to cause a
denial of service (memory corruption) or possibly have unspecified
other impact via a crafted MP4 file, because access to the data
structure has different expectations about layout as a result of
this type confusion.
Fixed by
73f38b4296
- CVE-2018-14403: MP4NameFirstMatches in mp4util.cpp in MP4v2 2.0.0
mishandles substrings of atom names, leading to use of an
inappropriate data type for associated atoms. The resulting type
confusion can cause out-of-bounds memory access.
Fixed by
51cb6b36f6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 0a860f21e1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
