The build of avrdude sometimes fails with:
avrdude: installs files in /home/autobuild/autobuild/instance-1/output-1/target//home/autobuild/autobuild/instance-1/output-1
This is due to an issue in the installation logic for the Python
code. However, our avrdude.mk doesn't explicitly support building
avrdude's Python support, so it's really only by luck (or lack
thereof) that sometimes host-swig and python3 end up built before
avrdude, causing avrdude to build its Python support, which installs
at the wrong location.
In order to address this, we add a small patch, submitted upstream,
that allows to explicitly disable Python support, which we then use in
avrdude.mk.
The actual Python issue can be investigated at a later point if
someone needs it. But in any case, being able to explicitly disable
Python support if not needed is useful.
Fixes:
http://autobuild.buildroot.net/results/f18d47289d8b4dee768275a468c25b4f4399cf8c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes https://autobuild.buildroot.net/results/f32ae62961aac7e8344f4be109040e7de2eb415e/
The openssl logic in ecryptfs uses the openssl engines API, which is always
available in libressl, but only available in libopenssl when
BR2_PACKAGE_LIBOPENSSL_ENGINES is enabled, leading to build failures when it
is not:
ecryptfs_key_mod_openssl.c: In function 'ecryptfs_openssl_read_key':
ecryptfs_key_mod_openssl.c:305:9: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
305 | ENGINE_load_builtin_engines();
Fix it by only passing --enable-openssl if libressl or (libopenssl + engines
support) is enabled.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes https://autobuild.buildroot.net/results/9d4e2f156d76e2acc83e3a25adb5e5cf0705e7c6/
configure:781: checking whether the C compiler (/home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 ) works
configure:797: /home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c 1>&5
configure:794:1: error: return type defaults to 'int' [-Wimplicit-int]
794 | main(){return(0);}
| ^~~~
configure: failed program was:
#line 792 "configure"
#include "confdefs.h"
main(){return(0);}
Wipe uses a very old configure script where the compile checks are missing
the return type on main(), breaking the configure step with >= gcc-15.
As a workaround, use AUTORECONF to regenerate the configure script.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a major version bump, because it could break user code that depends
on the (wrong) previous logic fixed by the new release
See the release notes:
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.0
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.1
This fixes the following vulnerabilities:
- CVE-2024-6839:
corydolphin/flask-cors version 4.0.1 contains an improper regex path
matching vulnerability. The plugin prioritizes longer regex patterns
over more specific ones when matching paths, which can lead to less
restrictive CORS policies being applied to sensitive endpoints. This
mismatch in regex pattern priority allows unauthorized cross-origin
access to sensitive data or functionality, potentially exposing
confidential information and increasing the risk of unauthorized
actions by malicious actors.
https://www.cve.org/CVERecord?id=CVE-2024-6839
- CVE-2024-6844:
A vulnerability in corydolphin/flask-cors version 4.0.1 allows for
inconsistent CORS matching due to the handling of the '+' character in
URL paths. The request.path is passed through the unquote_plus
function, which converts the '+' character to a space ' '. This
behavior leads to incorrect path normalization, causing potential
mismatches in CORS configuration. As a result, endpoints may not be
matched correctly to their CORS settings, leading to unexpected CORS
policy application. This can cause unauthorized cross-origin access or
block valid requests, creating security vulnerabilities and usability
issues.
https://www.cve.org/CVERecord?id=CVE-2024-6844
- CVE-2024-6866:
corydolphin/flask-cors version 4.01 contains a vulnerability where the
request path matching is case-insensitive due to the use of the
`try_match` function, which is originally intended for matching hosts.
This results in a mismatch because paths in URLs are case-sensitive,
but the regex matching treats them as case-insensitive. This
misconfiguration can lead to significant security vulnerabilities,
allowing unauthorized origins to access paths meant to be restricted,
resulting in data exposure and potential data leaks.
https://www.cve.org/CVERecord?id=CVE-2024-6866
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerabilities:
- CVE-2023-5341:
A heap use-after-free flaw was found in coders/bmp.c in ImageMagick.
https://www.cve.org/CVERecord?id=CVE-2023-5341
- CVE-2025-55004:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, ImageMagick is
vulnerable to heap-buffer overflow read around the handling of images
with separate alpha channels when performing image magnification in
ReadOneMNGIMage. This can likely be used to leak subsequent memory
contents into the output image. This issue has been patched in version
7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55004
- CVE-2025-55005:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, when preparing
to transform from Log to sRGB colorspaces, the logmap construction
fails to handle cases where the reference-black or reference-white
value is larger than 1024. This leads to corrupting memory beyond the
end of the allocated logmap buffer. This issue has been patched in
version 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55005
- CVE-2025-55160:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to versions 6.9.13-27 and 7.1.2-1,
there is undefined behavior (function-type-mismatch) in splay tree
cloning callback. This results in a deterministic abort under UBSan
(DoS in sanitizer builds), with no crash in a non-sanitized build.
This issue has been patched in versions 6.9.13-27 and 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55160
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerability:
- CVE-2025-6965:
There exists a vulnerability in SQLite versions before 3.50.2 where
the number of aggregate terms could exceed the number of columns
available. This could lead to a memory corruption issue. We recommend
upgrading to version 3.50.2 or above.
https://www.cve.org/CVERecord?id=CVE-2025-6965
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though this is not mentioned in the release notes:
- https://github.com/containers/netavark/releases/tag/v1.16.0
- https://github.com/containers/netavark/releases/tag/v1.16.1
According to https://bugzilla.redhat.com/show_bug.cgi?id=2383941,
the fix for the CVE has been merged upstream, and is in netavark
since v1.16.0.
This fixes the following vulnerability:
- CVE-2025-8283:
A vulnerability was found in the netavark package, a network stack for
containers used with Podman. Due to dns.podman search domain being
removed, netavark may return external servers if a valid A/AAAA record
is sent as a response. When creating a container with a given name,
this name will be used as the hostname for the container itself, as
the podman's search domain is not added anymore the container is using
the host's resolv.conf, and the DNS resolver will try to look into the
search domains contained on it. If one of the domains contain a name
with the same hostname as the running container, the connection will
forward to unexpected external servers.
https://www.cve.org/CVERecord?id=CVE-2025-8283
Also bump package/aardvark-dns in the same lockstep, as advised in
the packages .mk version comments.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GCC-15 defaults to C23, which changes the meaning of an empty parameter
list:
https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters
Leading to a build failure:
tsserve.c: In function ‘set_child_exit_handler’:
tsserve.c:2988:21: error: assignment to ‘__sighandler_t’ {aka ‘void (*)(int)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
2988 | action.sa_handler = on_child_exit;
Add a patch from an upstream PR to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 0d643a8636 which removed the
BR2_PACKAGE_LIGHTTPD_LIBEV symbol was originally meant for next and
therefore introduced the "Legacy options removed in 2025.11" comment.
However, in the end it was still applied to master for 2025.08, so the
legacy symbol was incorrectly placed.
Fix that.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The github repo was deleted and moved to codeberg, so use that instead:
https://lwn.net/Articles/926101/
It is unclear if the auto generated tarballs from codeberg are reproducible,
so instead fetch through git.
[Peter: set _CPE_ID_VERSION to the correct value]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bufix release fixing a number of issues:
- Bug 5352: Do not get stuck in RESPMOD after pausing peer read(2)
- Bug 5489: Fix "make check" linking on Solaris
- Fix SNMP cacheNumObjCount -- number of cached objects
- Do not duplicate received Surrogate-Capability in sent requests
- Fix Mem::Segment::open() stub to fix build without shm_open()
- ... and CI and documentation updates
https://github.com/squid-cache/squid/releases/tag/SQUID_6_14
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since Buildroot commit [1] updating qemu defconfigs from Kernel 6.6.32
to 6.12.9, qemu_aarch64_ebbr_defconfig, qemu_aarch64_sbsa_defconfig
and qemu_arm_ebbr_defconfig can fail to build with error:
/bin/sh: 1: python3: not found
make[7]: *** [drivers/gpu/drm/msm/Makefile:182: drivers/gpu/drm/msm/generated/a2xx.xml.h] Error 127
The issue can happen on build hosts without Python, and if the Linux
kernel is built before any package having host-python3 in its
dependencies (e.g. host-qemu, optee-os, ...).
Starting with Linux 6.10, the arm and arm64 architecture defconfigs need
python3 to build. [2]
This commit fixes this issue by adding
BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3=y in those defconfigs.
[1] 44075c1955
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=0fddd045f88e34d6160785a3a5e506d374566454
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Romain Naour <romain.naour@gmail.com>
[Julien:
- reword commit log to add the commit introducing the issue
- fix qemu_aarch64_sbsa_defconfig which has the same issue
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch fixes the CPE ID for both go-bin and go-src packages.
The go-src package did had a CPE ID because GO_SRC_CPE_ID_VENDOR is
defined but the generated CPE ID would be the following:
cpe:2.3:a:golang:go-src:*:*:*:*:*:*:*:*
The CPE product go-src doesn't match to anything and should be 'go'
instead.
For go-bin no CPE_ID variable were defined so no CPE ID would be
generated if using a pre-build toolchain.
This patch duplicate the definition of the CPE_ID variables, I didn't
put the definition in the 'package/go/go.mk' file to avoid generate a
CPE for the go virtual package.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes: https://autobuild.buildroot.net/results/9c40c86a42882a6d56eb6d6d1418781a980b6f8f/
The pthread support uses pthread_atfork(), which is not available on nommu:
cap-ng.c: In function 'init_lib':
cap-ng.c:225:9: error: implicit declaration of function 'pthread_atfork';
did you mean 'pthread_join'? [-Wimplicit-function-declaration]
So disable pthread support on nommu to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Setting the "update" field in the CPE ID to * doesn't actually make
much sense, as * is a wildcard. Instead, this field should really
reflect the "subrelease" / "update" of the package, which unless
specified explicitly by the package .mk file, is empty.
Using a wildcard causes a few CVEs to be incorrectly identified as
affecting some of our packages.
For example https://nvd.nist.gov/vuln/detail/CVE-2013-1428 has a
CPE configuration that goes like this:
cpe:2.3:a:tinc-vpn:tinc:*:pre6:*:*:*:*:*:* up to including 1.1
and this CPE configuration is currently identified as affecting our
package. This isn't correct as our package is using 1.0.36, not a
"pre6" version. But because the CPE ID generated by Buildroot uses *
as the "update" field, and * is the wildcard, it does match with this
CPE configuration.
After this change, two CVEs are no longer identified as affecting
Buildroot packages:
https://nvd.nist.gov/vuln/detail/CVE-2013-1428https://nvd.nist.gov/vuln/detail/CVE-2017-9454
and in both cases they are indeed CVEs not affecting our package.
Reported-by: Titouan Christophe <titouan.christophe@mind.be>
Cc: Titouan Christophe <titouan.christophe@mind.be>
Cc: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Fixes: https://autobuild.buildroot.net/results/8d14173f31922a737c326be75aa24c9f9471342a/
The vde2 source code uses empty argument function pointer prototypes like:
typedef ssize_t (* ssize_fun)();
extern ssize_fun vdehist_vderead;
In C17 and earlier, such prototypes means unknown number of arguments,
whereas with C23 it means no arguments, leading to build failures:
libvdehist.c:39:27: error: initialization of 'ssize_fun' {aka 'long int
(*)(void)'} from incompatible pointer type 'ssize_t (*)(int, void *,
size_t)' {aka 'long int (*)(int, void *, long unsigned int)'}
[-Wincompatible-pointer-types]
Workaround it using -std=gnu99. Vde2 is provided both as a host and target
package, so do this unconditionally for both.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This patch bumps the zynqmp defconfigs to Linux 6.12.40.
The memory leak patch is included with the Linux 6.12.40 release tag, so it no
longer needs to be applied to these defconfigs:
9691533f6e
This patch has been run tested on the zynqmp zcu102 evaluation board.
This patch has been run tested on the kria kv260 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Now that the qspi.bin file is included for zynqmp images, the 32M vfat
partition is getting dangerously close to being full.
In the process of bumping Linux kernel 6.12.10 to 6.12.40, the size of the
default Linux kernel Image file for zynqmp products is increasing from 23.4M
to 26.9M. This is leaving less than 1M of free space in the vfat partition
meaning users may unknowingly exceed the 32M size by just adding Linux kernel
configs.
To avoid potential problems, this patch doubles the size of the vfat partition
to 64M, which should be plenty of space for any configuration.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This patch bumps the zynq defconfigs to Linux 6.12.40.
The memory leak patch is included with the Linux 6.12.40 release tag, so it no
longer needs to be applied to these defconfigs:
9691533f6e
This patch has been run tested on the zynq zc702 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
[Arnout: squash addition of the hash into the same patch]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This tool helps to update Linux stable releases.
The script uses the versions found in linux/linux.hash. For each of the
versions it downloads the related hash list and tries to find an updated
stable release. If found it updates all related files and hashes.
Signed-off-by: Gero Schwäricke <gero.schwaericke@grandcentrix.net>
[Arnout: commonalize the sed expression for linux and linux-headers]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Unbound is vulnerable to CVE-2025-5994: "Cache poisoning via the ECS-enabled
Rebirthday Attack" if built with --enable-subnet, which is not the case in
Buildroot, so mark it as not applicable.
https://nlnetlabs.nl/downloads/unbound/CVE-2025-5994.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit fecc337d21,
re-adding optional support for pulseuadio in ffmpeg.
This is possible now that the circular dependency:
pulseaudio -> libsoxr -> ffmpeg -> pulseaudio
has been broken between libsoxr and ffmpeg.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Having support for ffmpeg in libsoxr causes several circular
dependencies:
- pulseaudio -> libsoxr -> ffmpeg -> pulseaudio
(This one was worked around in
fecc337d21 by dropping the ffmpeg ->
pulseaudio dependency, but it's annoying as being able to output
audio from ffmpeg into pulseaudio seems useful)
- libopenmpt -> pulseaudio -> libsoxr -> ffmpeg -> libopenmpt
(This is one exists, and is fixed by this commit)
To fix both circular dependencies, we propose to drop the dependency
of libsoxr on ffmpeg, which is used to get some optimized FFT
implementation. While not being useless, this is the point where
breaking the dependency seems the most logical.
Neither Debian nor Fedora build libsoxr with ffmpeg support.
In order to achieve that, we add a new patch making the option
WITH_AVFFT actually effective. Since we no longer build against
ffmpeg, the previously added patch that was fixing the pkg-config file
is no longer needed.
Fixes:
https://autobuild.buildroot.net/results/bbfce69f35cafd56245ebeae79086a8b64592a16/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A missing include causes a build failure with GCC 15.x. There are no
known autobuilder failures for this issue, but the following defconfig
allows to reproduce the issue:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_WEBRTC_AUDIO_PROCESSING=y
# BR2_TARGET_ROOTFS_TAR is not set
The affected code has completely changed in newer versions of
webrtc-audio-processing, so we add a non-upstream patch, which can be
dropped once we upgrade to a newer release.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This host package was only used as a build dependency of libsvgtiny,
which itself has been removed, so it can be dropped as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package hasn't been updated in years. It has new releases, such
as 1.0.8 from December 2023, but nobody updated to it.
Doing the version bump is not straightforward, and the original
package submitter, Peter Korsgaard, is no longer using it. This
package also had no reverse dependency, and no maintainer in the
DEVELOPERS file.
Therefore, let's drop this package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Peter: Add Config.in.legacy handling]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The new package_dir element contains the path of the package
directory. For Buildroot packages this is a path relative to the main
Buildroot directory, for packages from external trees an absolute
path.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Tested-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building the column store plugin (which gets automatically enabled
when Boost with a bunch of submodules is found) currently fails as it
requires a number of runtime checks that obviously cannot work when
cross-compiling.
OpenEmbedded has defined them as such:
-DLSTAT_FOLLOWS_SLASHED_SYMLINK_EXITCODE=0 \
-DSTAT_EMPTY_STRING_BUG_EXITCODE=0 \
-DMASK_LONGDOUBLE_EXITCODE=0 \
but it really isn't clear whether those values are completely correct
for all CPU architectures, especially the last one.
So instead, let's disable the column store plugin until someone
actually needs it and figures out how to set those variables properly.
The issue fixed by this commit can be reproduced using the following
defconfig:
BR2_aarch64=y
BR2_ARM_FPU_VFPV3D16=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_MARIADB=y
BR2_PACKAGE_MARIADB_SERVER=y
BR2_PACKAGE_BOOST=y
BR2_PACKAGE_BOOST_DATE_TIME=y
BR2_PACKAGE_BOOST_FILESYSTEM=y
BR2_PACKAGE_BOOST_REGEX=y
BR2_PACKAGE_BOOST_THREAD=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Config.in comment is between the main BR2_PACKAGE_MARIADB option
and its sub-options, causing the sub-options to not appear as nicely
indented in menuconfig.
Before:
[ ] mariadb
[ ] mariadb server
[ ] mariadb embedded server
After:
[ ] mariadb
[ ] mariadb server
[ ] mariadb embedded server
which is what we want.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
