Currently, by following the instructions in the manual and querying for
developers for a patch that changes path
package/foobar
the script reports both developers that have these entries in the
DEVELOPERS file:
F: package/foo/
F: package/foobar/
Starting from commit "afc112b0e4 utils/getdeveloperlib.py: fix issue
with hasfile()" get-developers script uses os.path.abspath() and
os.path.relpath().
The catch is that those functions return the absolute path and the
relative path without the trailing slash.
When the paths associated to a developer are then compared to the paths
a patch touches, using the string.startswith(), any substring returns
True, leading to developers for package/foo/ being wrongly reported
for package/foobar/ .
Fix this by re-adding the trailing slash after using relpath().
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Cc: James Knight <james.d.knight@live.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 29bb478a49)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2021-4069: vim is vulnerable to Use After Free
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 7600ca7960)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2021-43784: runc is a CLI tool for spawning and running
containers on Linux according to the OCI specification. In runc, netlink
is used internally as a serialization system for specifying the relevant
container configuration to the `C` portion of the code (responsible for
the based namespace setup of containers). In all versions of runc prior
to 1.0.3, the encoder did not handle the possibility of an integer
overflow in the 16-bit length field for the byte array attribute type,
meaning that a large enough malicious byte array attribute could result
in the length overflowing and the attribute contents being parsed as
netlink messages for container configuration. This vulnerability
requires the attacker to have some control over the configuration of the
container and would allow the attacker to bypass the namespace
restrictions of the container by simply adding their own netlink payload
which disables all namespaces. The main users impacted are those who
allow untrusted images with untrusted configurations to run on their
machines (such as with shared cloud infrastructure). runc version 1.0.3
contains a fix for this bug. As a workaround, one may try disallowing
untrusted namespace paths from your container. It should be noted that
untrusted namespace paths would allow the attacker to disable namespace
protections entirely even in the absence of this bug.
https://github.com/opencontainers/runc/releases/tag/v1.0.3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 0acaad1be2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently this .mk snippet results in unexpected behavior from
check-package:
|VAR_1 = VALUE1
|ifeq (condition)
|VAR_1 := $(VAR_1), VALUE2
|endif
Fix commit "163f160a8e utils/{check-package, checkpackagelib}:
consistently use raw strings for re.compile" that ended up doing this:
- CONCATENATING = re.compile("^([A-Z0-9_]+)\s*(\+|:|)=\s*\$\(\\1\)")
+ CONCATENATING = re.compile(r"^([A-Z0-9_]+)\s*(\+|:|)=\s*\$\(\\1\)")
But raw strings do not expect escaping when referencing \1 and the
pattern ends up searching for a raw '\\1' instead of an occurrence of
the first pattern inside parenthesis.
|$ python3
|Python 3.8.10 (default, Sep 28 2021, 16:10:42)
|[GCC 9.3.0] on linux
|Type "help", "copyright", "credits" or "license" for more information.
|>>> import re
|>>> p1 = re.compile('(foo)bar\\1')
|>>> p2 = re.compile(r'(foo)bar\\1')
|>>> p3 = re.compile(r'(foo)bar\1')
|>>> s1 = 'foobarfoo'
|>>> s2 = 'foobar\\1'
|>>> print(p1.search(s1))
|<re.Match object; span=(0, 9), match='foobarfoo'>
|>>> print(p2.search(s1))
|None
|>>> print(p3.search(s1))
|<re.Match object; span=(0, 9), match='foobarfoo'>
|>>> print(p1.search(s2))
|None
|>>> print(p2.search(s2))
|<re.Match object; span=(0, 8), match='foobar\\1'>
|>>> print(p3.search(s2))
|None
|>>>
So use '\1' instead of '\\1' in the raw string.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 5bbedea9c2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As stated on www.pcre.org:
You can download the current release of the PCRE2 library from its
official home on GitHub
[...]
Note that the former ftp.pcre.org FTP site is no longer available.
Update _SITE URL to the official home on Github.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
[yann.morin.1998@free.fr: use Github, not SourceForge]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cc570eff96)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The message attribute does not exist in python3, see PEP-0352:
https://www.python.org/dev/peps/pep-0352/
Fixes:
Traceback (most recent call last):
File "utils/scanpypi", line 743, in <module>
main()
File "utils/scanpypi", line 693, in main
if 'buildutils' in err.message:
AttributeError: 'ImportError' object has no attribute 'message'
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit c3029878c5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2021-4048: An out-of-bounds read flaw was found in the CLARRV,
DLARRV, SLARRV, and ZLARRV functions in lapack through version 3.10.0,
as also used in OpenBLAS before version 0.3.18. Specially crafted
inputs passed to these functions could cause an application using
lapack to crash or possibly disclose portions of its memory.
- Drop first and second patches (already in version)
https://github.com/xianyi/OpenBLAS/blob/v0.3.18/Changelog.txt
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.16.11 (released 2021-12-02) includes fixes to the compiler, runtime, and the
net/http, net/http/httptest, and time packages.
go1.16.12 (released 2021-12-09) includes security fixes to the syscall and
net/http packages.
go1.16.13 (released 2022-01-06) includes fixes to the compiler, linker, runtime,
and the net/http package.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following vulnerabilities:
- CVE-2021-42374: An out-of-bounds heap read in Busybox's unlzma applet
leads to information leak and denial of service when crafted
LZMA-compressed input is decompressed
- CVE-2021-42375: An incorrect handling of a special element in Busybox's
ash applet leads to denial of service when processing a crafted shell
command, due to the shell mistaking specific characters for reserved
characters. This may be used for DoS under rare conditions of filtered
command input
- CVE-2021-42376: A NULL pointer dereference in Busybox's hush applet leads
to denial of service when processing a crafted shell command, due to
missing validation after a \x03 delimiter character. This may be used for
DoS under very rare conditions of filtered command input.
- CVE-2021-42377: An attacker-controlled pointer free in Busybox's hush
applet leads to denial of service and possible code execution when
processing a crafted shell command, due to the shell mishandling the &&&
string. This may be used for remote code execution under rare conditions
of filtered command input.
For details, see:
https://jfrog.com/blog/unboxing-busybox-14-new-vulnerabilities-uncovered-by-claroty-and-jfrog/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop second patch (already in version)
- Fix CVE-2021-43400: An issue was discovered in gatt-database.c in BlueZ
5.61. A use-after-free can occur when a client disconnects during D-Bus
processing of a WriteValue call.
http://www.bluez.org/release-of-bluez-5-62
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1e48b159dc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
pause() is defined in glibc since the very early times; it appears in
upstream commit 28f540f45bba (initial import) in 1995 [0].
Bluez has been defining a function named pause() for ages too, since
comit caab74c97542 (media: Implement new callbacks for pass-through
operations) in 2013 [1]
With the recent bump to glibc 2.34.xxx, the build now fails because the
two pause() clash:
profiles/audio/media.c:1284:13: error: conflicting types for 'pause'
1284 | static bool pause(void *user_data)
| ^~~~~
In file included from /tmp/instance-0/output-1/per-package/bluez5_utils/host/s390x-buildroot-linux-gnu/sysroot/usr/include/bits/sigstksz.h:24,
from /tmp/instance-0/output-1/per-package/bluez5_utils/host/s390x-buildroot-linux-gnu/sysroot/usr/include/signal.h:328,
from /tmp/instance-0/output-1/per-package/bluez5_utils/host/bin/../s390x-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib/gbacktrace.h:36,
from /tmp/instance-0/output-1/per-package/bluez5_utils/host/bin/../s390x-buildroot-linux-gnu/sysroot/usr/include/glib-2.0/glib.h:34,
from profiles/audio/media.c:21:
/tmp/instance-0/output-1/per-package/bluez5_utils/host/s390x-buildroot-linux-gnu/sysroot/usr/include/unistd.h:489:12: note: previous declaration of 'pause' was here
489 | extern int pause (void);
| ^~~~~
The culprit is indeed glibc 2.34, as can be seen in this result matrix:
\ bluez5_utils
glibc \ 5.60 | 5.61
-------\-------+--------
2.33 | OK | OK
-------+-------+--------
2.34 | KO | KO
Even though we first bumped to glibc 2.34, then to blues5_utils 5.61,
we did not notice build issues with bluez5_utils 5.60 because the two
bumps were too close to each other for the failure to trigger in the
autobuilders.
The underlying reason that pause() is now causing issues with glibc 2.34
is not obvious: glibc is a big beast, and finding such issues is not
easy. However, we can see that the pause() provided by NPTL has been
dropped in favour of the generic one, so maybe this is causing symbol
visibility or weakness to change or something...
We fix that by renaming the local pause() in bluez5_utils with a
namespace-prefix, like some other functions there already have.
Fixes:
- http://autobuild.buildroot.org/results/c4f/c4fbface34be8815838fd7201621d7a8fddd32c5/
- http://autobuild.buildroot.org/results/62b/62b88740f19fbe4a1ad7959dc141d539eb88c1f8/
[0] https://sourceware.org/git/?p=glibc.git;a=commit;h=28f540f45bbacd939bfd07f213bcad2bf730b1bf
[1] caab74c975
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: extend commit log with the glibc culprit]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a02927b94a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Build of avrcp without a2dp is broken since commit
fb9fc969d9:
/home/buildroot/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/9.3.0/../../../../x86_64-buildroot-linux-uclibc/bin/ld: profiles/audio/bluetoothd-avrcp.o: in function `avrcp_handle_set_volume':
avrcp.c:(.text+0x9c4): undefined reference to `media_transport_update_device_volume'
However, build of a2dp without avrcp is also broken:
/data/buildroot-autobuilder/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv32-buildroot-linux-gnu/10.2.0/../../../../riscv32-buildroot-linux-gnu/bin/ld: profiles/audio/bluetoothd-media.o: in function `.L50':
media.c:(.text+0x508): undefined reference to `avrcp_unregister_player'
/data/buildroot-autobuilder/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/riscv32-buildroot-linux-gnu/10.2.0/../../../../riscv32-buildroot-linux-gnu/bin/ld: profiles/audio/bluetoothd-media.o: in function `match_endpoint_by_path':
media.c:(.text+0x824): undefined reference to `avrcp_register_player'
Fixes:
- http://autobuild.buildroot.org/results/d54cdfc03212fff772a863d1bc8afd3cfb605831
- http://autobuild.buildroot.org/results/64d75af986a4d6e9c5a176efb6e22046f4d82350
So make a single audio option for a2dp and avrcp
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit aedf2c83d0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Build of hid without hog is broken since commit
fb9fc969d9:
/home/buildroot/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/9.3.0/../../../../i586-buildroot-linux-musl/bin/ld: profiles/input/bluetoothd-manager.o: in function `input_init':
manager.c:(.text+0x2fd): undefined reference to `input_set_auto_sec'
Fixes:
- http://autobuild.buildroot.org/results/9222879c9fe958e01e33f69531270355ea016d17
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9850f262fd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BlueZ builds a lot of Classic BT profiles by default but allows
to disable them. This is especially handy when only BLE is needed
and enabled in the kernel.
Otherwise this yields warnings like this on bootup:
profiles/network/bnep.c:bnep_init() kernel lacks bnep-protocol support
src/plugin.c:plugin_init() System does not support network plugin
Also it allows to disable btmon which should not be needed on
production systems and is ~800KB in size.
Expose those options but default to 'y' to no break existing
configurations.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit fb9fc969d9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release notes:
http://www.bluez.org/release-of-bluez-5-59/http://www.bluez.org/release-of-bluez-5-60/
Added configure option to disable manpages to avoid rst2man dependency
introduced by version 5.59.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 861775ebbe)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Changelog:
https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ChangeLog
Needed for bluez5_utils bump to version 5.59.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b5bab43e13)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We define _DEFAULT_SOURCE in mkpasswd.c to suppress a compiler warning.
In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from [...]/buildroot/output/arm64/build/host-mkpasswd/mkpasswd.c:24:
/usr/include/features.h:187:3:
187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
| ^~~~~~~
As per GLIBC 2.20 release notes[1]:
The _BSD_SOURCE and _SVID_SOURCE feature test macros are no longer
supported; they now act the same as _DEFAULT_SOURCE (but generate a
warning). Except for cases where _BSD_SOURCE enabled BSD interfaces
that conflicted with POSIX (support for which was removed in 2.19),
the interfaces those macros enabled remain available when compiling
with _GNU_SOURCE defined, with _DEFAULT_SOURCE defined, or without
any feature test macros defined.
[1] https://lwn.net/Articles/611162/
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 9616ade222)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream maintainer, now also maintainer in Buildroot.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit afdd3b2afc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cpe:2.3🅰️kernel:util-linux is a valid CPE identifier for this package:
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Akernel%3Autil-linux
Inherit the values from util-linux; they really are, and have to be,
the same.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: inherit values from util-linux]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit bfe518b068)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 0cfa165948 (package/pkg-utils.mk: introduce "name" field in
show-info output) did what it said, but did so in the generic show-info
part, thus it was also added to filesystems (rootfs), the other kind of
entity that show-info reports on.
Only packages have a "name"; filesystems do not. Instead, they already
have an 'image_name'.
Move the 'name' field to the package-related part of show-info.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 471ecea5ee)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The unmatched escaped single-quote lies in the middle of a few
function calls, so they too must be fake-closed to properly fix
colour highlighting in some editors.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cba51c7f5a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages install nothing in target nor staging, but install images
(like the kernel vmlinux, or a bootloader boot blob...)
If we want to appropriately account for the files installed by each
package, we also need to take images/ into account.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5d00fecb7d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When calling 'printvars', the 'suitable-host-package' macro is printed
(a macro is just a variable like the others, after all, just with some
parameters). Because it is printed as a variable, it is missing its
parameters, but it still tries to evaluate the $(shell) construct.
This causes spurious warning:
make[1]: support/dependencies/check-host-.sh: Command not found
Only try and call the script if there is actually a tool to check for.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 77304e5143)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the build_dir field is reported relative to $(BASE_DIR), to
avoid leaking local paths.
However, BASE_DIR is not a directory that is very convenient: for
in-tree builds, it is $(CONFIG_DIR)/output/, while for out-of-tree
builds, it is $(CONFIG_DIR). This difference is purely an idiosyncracy
of how out-of-tree builds have been implemented in Buildroot, and is
not under the control of the user.
What the user is in control of, however, is where the .config file is
located. This, really, is the directory we should base relative paths
on.
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 76c4df324d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
