A few conflicts had to be resolved:
- Version number and hash for mesa3d-headers/mesa3d
- Patches added in qemu, and the qemu version number
- The gnuconfig README.buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.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>
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>
perf by itself is not a standalone package; instead, it is part of a
bigger package, linux-tools.
Even though perf is the only one to need kernel .config fixups, we still
do it in a generic way, as it blends nicely in the existing variables,
which all use a loop over all the tools.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.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>
The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].
To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.
When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].
But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.
So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).
In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _
But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
Error in reading or end of file.
Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
Error in reading or end of file.
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
Error in reading or end of file.
* Memory initialization
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]:
Error in reading or end of file.
Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
Error in reading or end of file.
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n
The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.
So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.
Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.
Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.
Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
While cross-compiling, qt5webengine is building a host tool, 'gn', and
by default wants to link it statically with libstdc++, when the tool is
otherwise dynamically linked with other libraries:
$ ldd 3rdparty/gn/out/Release/gn
linux-vdso.so.1 (0x00007ffc1c999000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000)
libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000)
Not all ditributions have the static libraries installed by default; for
example, on Fedora, libstdc++-static is not installed on a fresh system,
leading to build issues:
[185/185] LINK gn
FAILED: gn
/usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
/usr/bin/ld : unable to find -lstdc++
[...]
Project ERROR: GN build error!
The root cause is the addition in [0] of a command line option to the
build of gn, that requests static linking with libstdc++ by default.
Explicitly pass that option now, to avoid static linking with libstdc++
and get a fully dynamicallty linked executable:
$ ldd 3rdparty/gn/out/Release/gn
linux-vdso.so.1 (0x00007ffd3f160000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000)
libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000)
[0] cfab9198a9 (diff-905c8f054808213577c0a92d1b704615)
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Gaël Portay <gael.portay@collabora.com>
[yann.morin.1998@free.fr:
- rewrite the commit log with extra details and explanations
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
- 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>
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>
This patch adds support for the i.MX8M Nano EVK Board [1].
The final boot image is created from uboot and firmware binaries in post
image script board/freescale/common/imx/imx8-bootloader-prepare.sh
Note that this config is based on 4.19.35_1.1.0 ; hence, the kernel
configuration needs host-openssl to build.
[1] https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/evaluation-kit-for-the-i-mx-8m-nano-applications-processor:8MNANOD4-EVK
Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com>
Reviewed-by: Maeva Manuel <maeva.manuel@oss.nxp.com>
Reviewed-by: Julien Olivain <julien.olivain@oss.nxp.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
For some SoCs (i.e.: i.MX8M Nano for now), the DDR training firmware
in the boot image depends on the type of memory installed on a board
(LPDDR4, DDR4, etc...). The previous patch makes this firmware name
agnostic of the DDR type and uses ddr_fw.bin as a generic name. This
patch makes imx8-bootloader-prepare.sh use this generic name,
independently of the kind board DDR type.
Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com>
Reviewed-by: Maeva Manuel <maeva.manuel@oss.nxp.com>
Reviewed-by: Julien Olivain <julien.olivain@oss.nxp.com>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Several i.MX8 (e.g.: 8M, 8MM, 8MN) support many DDR types (LPDDR4, DDR4,
etc.), for which the DDR training is performed in the bootloader.
Some boards have LPDDR4 (e.g.: nitrogen8mn) and some others have the DDR4
(e.g.: NXP's reference board EVK). This patch allows the selection of either
of the binaries used to train the DDR.
Note that DDR and HDMI FW copies are now separated, which makes latter
being properly copied only for the relevant SoC (i.MX8MQ).
Suggested-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com>
Reviewed-by: Maeva Manuel <maeva.manuel@oss.nxp.com>
Reviewed-by: Julien Olivain <julien.olivain@oss.nxp.com>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Only some i.MX8 needs a DDR training firmware (8M, 8MM, 8MN). Some other
i.MX8 (QuadMax, QuadXPlus) rely on system controller for that task.
Suggested-by: Julien Olivain <julien.olivain@oss.nxp.com>
Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
[yann.morin.1998@free.fr:
- use the new variable to drive the firmware installation
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
This commit bumps ARC toolchain to arc-2020.03-release.
ARC GNU tools of version arc-2020.03-release bring some quite significant
changes like:
* Binutils 2.34 with additional ARC patches
* GCC 9.3 with additional ARC patches
* glibc 2.30 with additional ARC patches
* GDB 10-prerelease with additional ARC patches
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump U-Boot to 2020.04 and kernel to 5.4.42 versions.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fedora packaging use python3 as python interpreter since rust 1.24.0 [1]
by removing python2 tests from configure script [2].
Using python3 will help to remove python2 in a near future.
[1] 216b2d2771
[2] 216b2d2771/f/rust.spec (_314)
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Titouan Christophe <titouan.christophe@railnova.eu>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This includes the following changes:
5732f86 1.1.1
d8e9b32 pep8
4795bc7 Add Jackson Matheson to contributors
26db934 Merge branch 'master' of https://github.com/ljean/modbus-tk
837a12b Merge pull request #125 from jacksonmatheson/master
07b06f8 Fixed READ_WRITE_MULTIPLE_REGISTERS, added write_starting_address_FC23
Also update hash file formatting (2 spaces).
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit:
- bump Linux & U-Boot to linux4sam-2020.04
- bump at91bootstrap to v3.9.2
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Move the unconditional CONF_OPTS assignment toward the beginning of
the file, before the conditionals on optional dependencies. And use =
for this unconditional assignment instead of +=. No functional
changes, just to align with the coding style used in most other
packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump U-Boot to 2020.04 and kernel to version 5.6.3
Signed-off-by: Joris Offouga <offougajoris@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.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>
Fix the following CVEs:
- CVE-2019-17533: Mat_VarReadNextInfo4 in mat4.c in MATIO 1.5.17 omits
a certain '\0' character, leading to a heap-based buffer over-read in
strdup_vprintf when uninitialized memory is accessed.
- CVE-2019-20017: A stack-based buffer over-read was discovered in
Mat_VarReadNextInfo5 in mat5.c in matio 1.5.17.
- CVE-2019-20018: A stack-based buffer over-read was discovered in
ReadNextCell in mat5.c in matio 1.5.17.
- CVE-2019-20020: A stack-based buffer over-read was discovered in
ReadNextStructField in mat5.c in matio 1.5.17.
- CVE-2019-20052: A memory leak was discovered in Mat_VarCalloc in
mat.c in matio 1.5.17 because SafeMulDims does not consider the
rank==0 case.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gloox is a rock-solid, full-featured Jabber/XMPP client library,
written in clean ANSI C++. It makes writing spec-compliant clients
easy and allows for hassle-free integration of Jabber/XMPP
functionality into existing applications. gloox is released under the
GNU GPLv3. Commercial licensing and support are available.
Signed-off-by: Yair Ben Avraham <yairba@protonmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit backports an upstream patch made for gnupg2 into gnupg, in
order to fix build failures with gcc 10 due to the use of
-fno-common. Due to the code differences between upstream gnupg2 and
the old gnupg 1.x, the backport is in fact more a rewrite than an
actual backport.
Fixes:
http://autobuild.buildroot.net/results/496a18833505dc589f7ae58f2c7e5fe80fe9af79/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Installing qt5declarative examples on fast/fast/multicore machines sometimes
failes with a variation of the following error messages:
- Cannot touch [...]/chapter5-listproperties/app.qml: No such file or directory
- Error copying [...]/chapter2-methods/app.qml: Destination file exists
Fix it by using OTHER_FILES instead of a seperate qml files install target
to fix the race between install_target, install_qml and install_sources.
Fixes:
- https://gitlab.com/buildroot.org/buildroot/-/jobs/565470221
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Reworked patch and commit log]
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
