Commit [1] introduced a patch addressing CVE-2021-23159. Since then,
CVE-2023-34432 ([2]) remained the only unresolved CVE reported
against the sox package in pkg-stat. This patch adds CVE-2023-34432
to the list of ignored CVEs for sox, based on the report from the
Debian Security Tracker ([3]) and the sox issue tracker ([4]), both
indicate that the patch introduced in [1] also resolves this CVE.
[1] 14aa0f5ec1 package/sox: add fix for CVE-2021-23159, CVE-2021-23172, CVE-2023-34318
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-34432
[3] https://security-tracker.debian.org/tracker/CVE-2023-34432
[4] https://sourceforge.net/p/sox/bugs/367/
Signed-off-by: Tim Soubry <tim.soubry@mind.be>
[Julien: change commit ref [1] to use commit id from master branch]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The following error appeared on the autobuilder for host using
host-gcc15:
```
p11_attr.c: In function 'pkcs11_addattr_bool':
p11_attr.c:126:25: error: expected identifier or '(' before 'true'
126 | static CK_BBOOL true = CK_TRUE;
| ^~~~
p11_attr.c:127:25: error: expected identifier or '(' before 'false'
127 | static CK_BBOOL false = CK_FALSE;
| ^~~~~
p11_attr.c:128:44: error: lvalue required as unary '&' operand
128 | pkcs11_addattr(tmpl, type, value ? &true : &false, sizeof(CK_BBOOL));
| ^
p11_attr.c:128:52: error: lvalue required as unary '&' operand
128 | pkcs11_addattr(tmpl, type, value ? &true : &false, sizeof(CK_BBOOL));
| ^
make[3]: *** [Makefile:646: libp11_la-p11_attr.lo] Error 1
```
This is due to the change in the default C language version in GCC15.
This patch backport the upstream patch that fix that issue by not using
the keywords.
Fixes: https://autobuild.buildroot.org/results/da7/da71db9b04f181b9d2e72df73ac8541709f5a1d4
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This gives a proper cpe-id string to the tailscale buildroot package
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following vulnerabilities:
- CVE-2023-4256:
Within tcpreplay's tcprewrite, a double free vulnerability has been
identified in the tcpedit_dlt_cleanup() function within
plugins/dlt_plugins.c. This vulnerability can be exploited by
supplying a specifically crafted file to the tcprewrite binary. This
flaw enables a local attacker to initiate a Denial of Service (DoS)
attack.
https://www.cve.org/CVERecord?id=CVE-2023-4256
- CVE-2023-43279:
Null Pointer Dereference in mask_cidr6 component at cidr.c in
Tcpreplay 4.4.4 allows attackers to crash the application via crafted
tcprewrite command.
https://www.cve.org/CVERecord?id=CVE-2023-43279
- CVE-2024-22654:
tcpreplay v4.4.4 was discovered to contain an infinite loop via the
tcprewrite function at get.c.
https://www.cve.org/CVERecord?id=CVE-2024-22654
See the release notes:
https://github.com/appneta/tcpreplay/releases/tag/v4.5.1
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The website URL was outdated, resulting in an HTTP error 403 Forbidden
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This bump includes 23 minor or patch-level releases, mostly containing
bugfixes, and improvements on many filesystem backends and translations.
Specifically for the Buildroot package:
- Switch from libsoup (v2) to libsoup3, since gvfs v1.49.90
- Drop patch applied upstream
- Explicitely disable goa (gnome-online-accounts) which is enabled by default
in meson_options.txt
See the upstream changelog:
https://gitlab.gnome.org/GNOME/gvfs/-/blob/1.57.2/NEWS
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: remove .checkpackageignore entry to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The build complains about these being unused so drop them.
LLVM_ENABLE_TERMINFO option is removed since llvm 19.1.0 [1]
[1] 852aaf5407
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
[Romain: add upstream commit link]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This is a small bugfix release, mainly containing event handling fixes
for Wayland, and the possibility to explicitly configure the gamepad
support at build time.
Release notes:
https://wpewebkit.org/release/cog-0.18.5.html
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release note, see:
https://www.sudo.ws/releases/stable/#1.9.17p1
Fixes the following security issues:
- CVE-2025-32462: Sudo before 1.9.17p1, when used with a sudoers file that
specifies a host that is neither the current host nor ALL, allows listed
users to execute commands on unintended machines (since sudo 1.8.8)
https://www.sudo.ws/security/advisories/host_any/
- CVE-2025-32463: Sudo before 1.9.17p1 allows local users to obtain root
access because /etc/nsswitch.conf from a user-controlled directory is used
with the --chroot option (since sudo 1.9.4)
https://www.sudo.ws/security/advisories/chroot_bug/
Update the LICENSE.md hash for a change in copyright years:
30729312c2
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: add link to release note in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The BR2_ARCH_NEEDS_GCC_AT_LEAST_X guards were added in commit [1]
for toolchain-external-custom gcc versions from 4.8 to 12. No guard
was added for gcc 13 because is was the latest version at that time
(and the symbol BR2_ARCH_NEEDS_GCC_AT_LEAST_14 was not available
at that time).
Then, commit [2] and [3] added gcc 14 and 15 without adding
guards.
In order to prevent a Buildroot user selecting an external custom
toolchain that does not support a selected CPU, this commit adds all
the missing guards.
[1] eed1670d8a
[2] 7fa12e4f9e
[3] 5f1a38a41f
Reported-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This logic is to prepare for future gcc versions and their new
supported CPUs. As of today, gcc 15 is the latest gcc version
and all architectures and CPUs in Buildroot are supported by
this version.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
gcc 15 was introduced in Buildroot in commit [1].
In Buildroot, a user creates a build configuration in Kconfig
menus by selecting the CPU architecture and CPU first, then
a toolchain that support this CPU, then packages and system
configuration.
To make sure those Kconfig menus and choices behave correctly in that
order, we use a logic in which a CPU selects the Kconfig symbol
BR2_ARCH_NEEDS_GCC_AT_LEAST_N (with N being the needed gcc version).
Then, to make sure unsupported gcc version are hidden for a selected
CPU, a gcc version N has in fact a "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1)". For example, Cortex-A710 needs
at least gcc 12. See [2] and [3].
This means that when we introduce the latest gcc version with this
logic in place, we already need this BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1)
symbol defined. Doing so is desirable to avoid forgetting to add it
later. See for example commit [4], adding those missing dependencies
for gcc 13 and 14.
Since in Buildroot we currently keep 3 actively maintained gcc
versions, adding a new gcc version N in Buildroot should:
- add the BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1) symbol
- add package/gcc N
- switch the default gcc from N-2 to N-1
- drop package/gcc N-3
Then, once this new gcc N is added, new CPUs supported by that version
can be introduced, by selecting BR2_ARCH_NEEDS_GCC_AT_LEAST_N.
All this logic will be ready for future gcc versions. This was also
described in commit log [5].
This commit simply adds the BR2_ARCH_NEEDS_GCC_AT_LEAST_16 symbol.
It is worth mentioning that, at the time of this commit, gcc 16 is not
released yet. This release number 16 is already known, though. See [6].
For reference, this was discussed in [7].
[1] 75891397ab
[2] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.05/arch/Config.in.arm#L514
[3] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.05/package/gcc/Config.in.host#L27
[4] 6f231d3003
[5] eab17d763c
[6] https://gcc.gnu.org/gcc-16/changes.html
[7] https://lore.kernel.org/buildroot/877c0v1sn1.fsf@dell.be.48ers.dk/T/#m45688e25632401029e4c0d989072e1d3e1a59854
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The daq package fails to build with GCC14 toolchains:
```
daq_nfq.c: In function 'SetPktHdr':
daq_nfq.c:395:37: error: passing argument 2 of 'nfq_get_payload' from incompatible pointer type [-Wincompatible-pointer-types]
395 | int len = nfq_get_payload(nfad, (char**)pkt);
| ^~~~~~~~~~~
| |
| char **
```
The issue can be reproduced with the following config:
```
cat > daq.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_DAQ=y
BR2_PACKAGE_LIBDNET=y
BR2_PACKAGE_LIBNETFILTER_QUEUE=y
EOF
```
This patch port a patch taken from openembedded meta-networking [1] and
is tested with test-pkg:
```
$ ./utils/test-pkg -c daq.config -p daq
```
[1] https://layers.openembedded.org/layerindex/recipe/37594/
Fixes: https://autobuild.buildroot.org/results/c69/c69ab134463a18eec65ded836aecf89a5cb4a75c/build-end.log
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit [1] backported an upstream patch to address CVE-2025-46836 that
included a regression.
Upstream later fixed this regression in commit [2].
This patch add that fix to correct the issue introduced by the original
patch.
[1] 323aaa9f54 package/net-tools: add upstream security fix for CVE-2025-46836
[2] ddb0e375fb/
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release note, see:
https://github.com/urllib3/urllib3/releases/tag/2.5.0
This fixes the following vulnerabilities:
- CVE-2025-50181:
urllib3 redirects are not disabled when retries are disabled on
PoolManager instantiation
- CVE-2025-50182:
urllib3 does not control redirects in browsers and Node.js
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: add link to release note in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following vulnerability:
- CVE-2023-34194:
StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in TinyXML
through 2.6.2 has a reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Jose-13 fixed the following security issue:
- CVE-2023-50967: latchset jose through version 11 allows attackers to cause
a denial of service (CPU consumption) via a large p2c (aka PBES2 Count)
value.
https://github.com/latchset/jose/issues/151
In addition, jose-14 worked around another DoS issue related to
decompression:
https://github.com/latchset/jose/pull/157
Drop now upstreamed patches:
- 0001-lib-hsh.c-rename-hsh-local-variable.patch: Upstream as of
3d5b287243
- 0002-man-add-option-to-skip-building-man-pages.patch: Upstream after
getting reworked to use -Ddocs=disabled as of
786b426df0
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: remove .checkpackageignore entries to fix check-package errors]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The syslinux runtime test (which is in fact a build-only test) ensures
that syslinux does get build at least once a week (via the gitlab-CI
weekly pipeline). Runtime testing would need much more work, though, but
nothing in syslinux is currently runtime tested anyway.
Reported-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The following error occurs on the autobuilder for builds with musl
libc.
```
CC util/bitmap.o
In file included from include/linux/bitmap.h:7,
from util/bitmap.c:9:
include/linux/bitops.h:4:10: fatal error: bits/wordsize.h: No such file or directory
4 | #include <bits/wordsize.h>
| ^~~~~~~~~~~~~~~~~
```
The error occurs because bits/wordsize.h is specific to glibc.
This patch applies an upstream fix that replaces the use of __WORDSIZE
with an internal macro, making the code portable across different libc.
Fixes: https://autobuild.buildroot.org/results/30d/30d6e407e6a0fc7d85062c2d56008755c70ca733/build-end.log
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 0.192 release of elfutils introduced the src/srcfiles.cxx program,
that lists all source files of a given ELF binary. As this is a C++
program, we need a toolchain that supports it.
Without it, the build system tries to use "no" as the CXX compiler,
resulting in the following errors :
/bin/sh: line 1: no: command not found
as can be seen here for example :
https://autobuild.buildroot.net/results/849/849221c794a469a423857a290db775d150b84900
Add a dependency to a CPP toolchain for the elfutils programs.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The elfutils programs require Glibc to be used as the C library. Show a
comment when this libc isn't used in the toolchain.
Suggested-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This package provides a reference, functional implementation of a
registry for distributing container images. Formerly the Docker
registry, it now also handles OCI images, so can be used to distribute
all kinds of container related images: classic Docker images, OCI
images, but also helms [0] and the likes, which are also packages as OCI
images in fact.
The upstream name of the package is just "distribution" [1], but this is
a bit too generic and unsearchable; distributions like Debian and Ubuntu
traditionally provides it as the "docker-registry" package, but this is
now misleading as it is not just for Docker anymore. So we decided to
name it "distribution-registry": it contains the upstream name and will
be searchable with the 'registry' part as well.
The built executable is named "registry", which is also a bit too
generic. Again, for the same reasons as above, we name it
"distribution-registry"; this also incidentally makes our golang-package
infra "just work" and do the right thing when it installs the package.
The upstream package provides a wrapper Makefile to build the package,
but it does not do more than our infra already does; the only little nit
is that it allows updating the version file (with git infra et al.). We
can just ignore that and update the version ourselves.
We also provide a minimalist configuration file: it exposes the registry
to localhost only, as a security measure. This file will have to be
overridden (e.g. in a rootfs-overlay) with proper authentication, and
with further locally meaningful setup anyway.
Finally, we also implement a run-time test that validates that we can
push and pull images to/from the registry. Since the registry is a big
go package, it takes time to start, so wait for it a little bit (and yet
a little bit more after it starts logging), and increase the timeouts
for commands that deal with the registry.
For this simple test, the registry is directly exposed with plain HTTP,
not HTTPS, so we must declare it as insecure, so that container tools
can reach it without custom options (e.g. without using skopeo's
--{src,dest}-tls-verify=false options).
We re-use skopeo to talk to the registry. This allows us to grab an
image from the Docker hub registry, and push it to our local registry,
then retrieve it back. Since we want to diffferentiate failures to grab
the image from the Docker Hub [2], from failures to push to our
registry, we do it in two steps: copy from Docker Hub to a local OCI
image, then push that to our registry.
Since both distribution-registry and skopeo are big go-based, statically
linked binaries, running both in the standard virtual machine does not
work: the 256MiB emulated in vexpress are not enough and cause segfaults
when running both at once. The vexpress also only accepts at most
256MiB, so we must use another machine; we decided to use the same as is
used by the podman teest case, which allows at least 1Gib, which is now
enough.
[0] https://helm.sh/
[1] https://github.com/distribution/distribution
[2] in case we reach the 100-pulls-a-day limitation
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Christian Stewart <christian@aperture.us>
Signed-off-by: Julien Olivain <ju.o@free.fr>
... and extend the skopeo runtime test to make use of those.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The container/image repository is the standards regpository that drives
the image management in container tools, like podman or skopeo. Besides
a Go library, it also prodvides the template configuration files used
by those tools; those files can also serve as default ones.
Install those files instead of the canned ones we cary in podman, and
change podman to use this new package too.
The registry file needs a fixup, as it by default does not allow
searching unqualified images (i.e. those that do not contain a registry
name) in a default registry, for security reasons. However, the Docker
Hub is traditionally a registry that can be accessed without being
specified, so we make that possible.
As was noted in ebbaac08e3 (package/podman: new package), "[p]roviding
actual files is going to be use-case dependent, and interested parties
will have to provide their own config files, e.g. in a rootfs overlay."
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For release note, see:
https://dev.gnupg.org/T7166
This version fixes a build error which can happen with 32-bit arm
configurations.
The issue can be reproduced with commands:
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_INSTRUCTIONS_THUMB2=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_LIBGCRYPT=y
EOF
make olddefconfig
make libgcrypt
Build is failing with output:
ec-nist.c: In function '_gcry_mpi_ec_nist256_mod':
ec-inline.h:902:5: error: 'asm' operand has impossible constraints or there are not enough registers
902 | __asm__ ("subs %3, %7, %10\n" \
| ^~~~~~~
Details for this buggix: https://dev.gnupg.org/T7226
Signed-off-by: Bram Oosterhuis <dev@bybram.com>
[Julien: reword commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
lpxelinux is like pxelinux, except it allows retrieving the files for
the kernel (with the KERNEL directive) and initrd (the path to initrd=
in the APPEND directive) from FTP or HTTP, rather than just from TFTP.
Using HTTP or FTP is musch faster than TFTP, so the boot time for big
kernels or big initrds is much shorter than with TFTP.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
[Julien: fix typo in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
syslinux is... special. It is a target package, but it is installed in
HOST_DIR *in the target install commands*: in addition to the boot files
that run on the target, syslinux installs a set of host tools that are
to be used at build time (e.g. extlinux, to prepare bootable media, like
an iso96660 image). Then, from HOST_DIR, the actual boot files are
copied into BINARIES_DIR (i.e. images/); we do it that way because the
boot files are scattered about everywhere in the build tree, while they
are all packed together in a single directory once installed.
However, there is no dependency between the target and image install
steps. So, when using top-level parallel builds, there is no guarantee
that the target install commands are finished before the image install
commands are started.
We fix that by first installing into a temporary location, as part of
the build step, and by then copying from there as part of the install
step. This ensures that the boot files are easily available, without
needing a dependency on the target install step, that we can't express.
Note that we do not change the actual installation into HOST_DIR: it can
be set up differently that our temporary location, and we do not want
to duplicate that setup here (it's going to diverge over time).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
At the moment, package stats indicates that libmpeg2 is affected by
https://nvd.nist.gov/vuln/detail/CVE-2022-37416
However, this CVE applies to a completely different piece of software,
that has the same name "libmpeg2" [1].
To avoid the confusion, let's add a proper CPE vendor to Buildroot's libmpeg2.
The library itself does not clearly identify any vendor name, and there isn't
any existing CPE on the NVD website. Since this library is not updated for
many years (maybe even before the introduction of the CPE system), but the
code is somehow related to the Videolan project, let's add this as the
vendor, which sould solve the matched CVE issue.
[1] https://github.com/ittiam-systems/libmpeg2
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: fix typo in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
When a new gcc version is introduced, for example gcc 15 in
commit [1], it should have also added a "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_15" to the previous gcc version.
This logic is described for external toolchains in commit [2],
for example. The internal Buildroot toolchains should have the
same logic. This logic existed for previous gcc version. See for
example the removal of gcc 12 in commit [3].
There is usually no problem, because all the three latest active gcc
versions supports all CPUs present in Buildroot.
However, the commit [4] recently added the support for the Arm
Cortex-A720 CPU, which needs at least gcc 14. Since there is no
logic preventing the selection of the gcc version, it is possible
to select an unsupported gcc version (i.e. gcc 13).
In such a case, the host-gcc-initial package configuration fails
with output:
Unknown cpu used in --with-cpu=cortex-a720
This commit fixes the issue by adding those missing dependencies.
Fixes:
https://autobuild.buildroot.org/results/918b90aee0b65f01efc241622015cb847b4e23a8/
[1] 75891397ab
[2] f577d8218f
[3] 58cf7c51da (66f7e875db173e5538d3511c8297acc1ba30da33_27_25)
[4] de374e06d8
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Strongswan allows to specify a path for PID and UNIX socket files at
compile time via the --with-piddir argument.
This is especially useful when Strongswan is running inside a container
where we may not want to share/mount the default path of /var/run inside
the container.
Let's add an option to configure the piddir.
Considering this is a critical path, let's add a default value to the
string option (which is currently the same as strongswan's default when
the option is missing) so that it is stable across strongswan releases
in Buildroot.
Signed-off-by: Martin Elshuber <martin.elshuber@theobroma-systems.com>
[Quentin: rewriting of commit title and commit log]
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
