Fixes the following security issue:
- wpa_supplicant P2P group information processing vulnerability (no CVE yet)
A vulnerability was discovered in how wpa_supplicant processing P2P
(Wi-Fi Direct) group information from active group owners. The actual
parsing of that information validates field lengths appropriately, but
processing of the parsed information misses a length check when storing a
copy of the secondary device types. This can result in writing attacker
controlled data into the peer entry after the area assigned for the
secondary device type. The overflow can result in corrupting pointers
for heap allocations. This can result in an attacker within radio range
of the device running P2P discovery being able to cause unexpected
behavior, including termination of the wpa_supplicant process and
potentially arbitrary code execution.
For more details, see the advisory:
https://w1.fi/security/2020-2/wpa_supplicant-p2p-group-info-processing-vulnerability.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[yann.morin.1998@free.fr: keep _PATCH near _VERSION and _SITE]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When a armv8 target is used in 32bits mode, xenomai fail to detect the
ARM architecture and abord the build. (__ARM_ARCH_7A__ is not defined
for armv8 cpus).
There are no autobuilder failures for this issue since cobalt is never
selected, but the following defconfig:
BR2_arm=y
BR2_cortex_a53=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_XENOMAI=y
BR2_PACKAGE_XENOMAI_COBALT=y
This was initialy reproduced using the raspberrypi3_defconfig with
Xenomai package with cobalt selected.
In order to use Xenomai on raspberrypi3 in 32 bits mode, one has to
select BR2_cortex_a7 instead of BR2_cortex_a53 (see a13a388dd4).
See:
https://gitlab.denx.de/Xenomai/xenomai/-/blob/v3.1/lib/cobalt/arch/arm/include/asm/xenomai/features.h#L52
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[yann.morin.1998@free.fr:
- switch to independent conditional 'default y'
- slightly reword the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
There are no autobuilder failures for this issue, but the following
defconfig:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_XENOMAI=y
BR2_PACKAGE_XENOMAI_COBALT=y
See:
https://gitlab.denx.de/Xenomai/xenomai/-/blob/v3.1/lib/cobalt/arch/arm/include/asm/xenomai/features.h#L56
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[yann.morin.1998@free.fr: fix the condition]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test RISC-V 64/musl, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test RISC-V 64/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch drops the local syslog.conf in favor of the one shipped with
sysklogd. The upstream syslog.conf sample differs from the Buildroot
one primarily in shifting to /var/log/syslog as the default for log
messages. It also comes with a dedicated /var/log/kern.log and some
commented-out filtering examples.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2020-11105: An issue was discovered in USC iLab cereal through
1.3.0. It employs caching of std::shared_ptr values, using the raw
pointer address as a unique identifier. This becomes problematic if an
std::shared_ptr variable goes out of scope and is freed, and a new
std::shared_ptr is allocated at the same address. Serialization fidelity
thereby becomes dependent upon memory layout. In short, serialized
std::shared_ptr variables cannot always be expected to serialize back
into their original values. This can have any number of consequences,
depending on the context within which this manifests.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump to the latest git commit as this will fix the following CVEs:
git log|grep CVE
sox-fmt: validate comments_bytes before use (CVE-2019-13590) [bug #325]
fix possible null pointer deref in lsx_make_lpf() (CVE-2019-8357)
fft4g: bail if size too large (CVE-2019-8356)
fix possible overflow in lsx_(re)valloc() size calculation (CVE-2019-8355)
fix possible buffer size overflow in lsx_make_lpf() (CVE-2019-8354)
xa: validate channel count (CVE-2017-18189)
aiff: fix crash on empty comment chunk (CVE-2017-15642)
adpcm: fix stack overflow with >4 channels (CVE-2017-15372)
flac: fix crash on corrupt metadata (CVE-2017-15371)
wav: ima_adpcm: fix buffer overflow on corrupt input (CVE-2017-15370)
wav: fix crash writing header when channel count >64k (CVE-2017-11359)
hcom: fix crash on input with corrupt dictionary (CVE-2017-11358)
wav: fix crash if channel count is zero (CVE-2017-11332)
- Tweak configuration options due to
6ff0e9322f
- libgsm is now an optional dependency since
e548827ffc
- Add patch to put back --disable-stack-protector
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop upstream patch.
Use the new mode=release switch, this should automatically
disable features deemed not ready for use.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream changed version scheme: dropped leading 's', reflect it.
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
CVE-2020-28473: The package bottle from 0 and before 0.12.19 are vulnerable
to Web Cache Poisoning by using a vector called parameter cloaking. When
the attacker can separate query parameters using a semicolon (;), they can
cause a difference in the interpretation of the request between the proxy
(running with default configuration) and the server. This can result in
malicious requests being cached as completely safe ones, as the proxy would
usually not see the semicolon as a separator, and therefore would not
include it in a cache key of an unkeyed parameter.
In addition, bottle 0.12.18 fixed a compatibility issue with python 3.8+:
https://github.com/bottlepy/bottle/issues/1181
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mmc probing order has changed since commit 21b2cec61c04bd1 (mmc: Set
PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4), so get rid of
the hardcoded root=/dev/mmcblk1p2. The old vendor U-Boot unfortunately does
not have GPT support, so stick to MBR and use the legacy
root=PARTUUID=<disksignature>-<partition> format and set a fixed disk
signature, similar to how it was done for orangepi-r1 in commit 34cce93adb
(configs/orangepi_r1_defconfig: bump kernel to 5.10.10, u-boot to 2020.10).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 38d04e6b13, I did a last-minute change by adding the comment
to explain where the PARTLABEL was coming from, and introduced a typo in
that comment.
Fix it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Patch that pins mmc indexes was not accepted to mainline kernel. Drop that
patch and switch to GPT to use partition labels. For GPT the name of the
partition in genimage.cfg is used as the label for that partition. Note
that the default GPT partition table location conflicts with the SPL
location, so move GPT table after bootloaders.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
grpc has plugins for multiple programming languages, which are needed on
development machines only. Examples are grpc_cpp_plugin, grpc_ruby_plugin,
etc.
Even though before commit fedf3318e3,
grpc_cpp_plugin was not installed for target, all other plugins still were.
This causes additional build time and rootfs space.
As Buildroot does not support building a development environment for target,
these tools can be disabled.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In commit fedf3318e3, an obsolete patch to
support cross-compilation was removed, in favor of the upstream solution.
However, this caused a small change in behavior: for the target grpc, the
tool 'grpc_cpp_plugin' is now also built, while before it was not.
This tool is only really needed on development machines. Since Buildroot
does not support compilers and such on target itself, the tool is not
needed.
There exists an option gRPC_BUILD_GRPC_CPP_PLUGIN which can be set to 'OFF',
but disabling it in a cross-compilation context yields build failures.
Add a patch to fix that. This patch is intended to be upstreamed to grpc.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 903de16f5f added passing
'--with-libgrpc++' with the explanation:
"Use --with-libgrpc++ option as otherwise collectd will try to find
grpc++.pc which is not available."
At the time of above commit, grpc version in Buildroot was 1.23.0.
Since grpc 1.25.0, a grpc++.pc file _is_ generated from cmake builds.
Hence, remove passing --with-libgrpc++.
This change fixes a problem introduced by commit
fedf3318e3. As a side effect of that change, a
target version of 'grpc_cpp_plugin' was now created. When collectd was built
after grpc, even without grpc support in collectd enabled, the collectd
configure script would find this target grpc_cpp_plugin and try to use it
(which is not possible because it is built for target).
When not passing '--with-libgrpc++', collectd will instead find the host
version of grpc_cpp_plugin, which works fine.
There are still two underlying problems:
1. the target version of grpc_cpp_plugin is not actually needed. This will
be disabled in a subsequent commit.
2. collectd should not execute any grpc-related action if grpc support for
collectd is disabled. This problem has been reported upstream:
https://github.com/collectd/collectd/issues/3836
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Most of the toolchains now use gcc 9.x and kernel headers 5.9, instead
of gcc 8.x and kernel headers 5.4.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test Xtensa/uclibc, use a pre-built Bootlin toolchain.
To be noted: that fragment was in fact already using a Bootlin
bleeding-edge toolchain, because BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y is
missing from the fragment:
$ cat support/config-fragments/autobuild/br-xtensa-full.config >.config
$ make olddefconfig
$ grep BOOTLIN .config
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARCH_SUPPORTS=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_XTENSA_LX60_UCLIBC_BLEEDING_EDGE=y
# BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_XTENSA_LX60_UCLIBC_STABLE is not set
The original fragment was supposed to use a stable toolchain, so we
switch to explictly use a stable Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- add blurb about missing BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test x86-64/musl, use a pre-built Bootlin toolchain.
The previous configuration was for an Atom platform, but the Bootlin
toolchains only provide a Core i7 configuration. Since this is close
enough, we change to use this Core i7 configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test x86-64/uclibc, use a pre-built Bootlin toolchain.
The previous configuration was for Core2 platform, but the Bootlin
toolchains only provide a Core i7 configuration. Since this is close
enough, we change to use this Core i7 configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SPARC64/glibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SPARC/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test SH4/uclibc, use a pre-built Bootlin toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: drop BR2_sh4=y which is the default]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test RISC-V 32/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test PowerPC e500mc/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test PowerPC64le Power8/glibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Instead of using an external toolchain built specifically for the
autobuilders to test OpenRISC/uclibc, use a pre-built Bootlin
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
