Besides just updating a little terminology, remove the awkward
reference to "his" when referring to developers.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The openscap build can fail with the following error:
In file included from [...]/src/OVAL/probes/unix/linux/systemdunitproperty_probe.c:38:
[...]/src/OVAL/probes/unix/linux/systemdshared.h: In function ‘get_all_systemd_units’:
[...]/src/OVAL/probes/unix/linux/systemdshared.h:188:50: error: implicit declaration of function ‘basename’; did you mean ‘rename’? [-Wimplicit-function-declaration]
188 | char *unit_name_s = oscap_strdup(basename(value.str));
| ^~~~~~~~
| rename
In file included from [...]/src/OVAL/probes/unix/linux/systemdunitdependency_probe.c:37:
[...]/src/OVAL/probes/unix/linux/systemdshared.h: In function ‘get_all_systemd_units’:
[...]/src/OVAL/probes/unix/linux/systemdshared.h:188:50: error: implicit declaration of function ‘basename’; did you mean ‘rename’? [-Wimplicit-function-declaration]
188 | char *unit_name_s = oscap_strdup(basename(value.str));
| ^~~~~~~~
| rename
This error happens when:
- dbus is enabled in the configuration, making openscap build probes
code
- the toolchain uses musl, which does not declare basename() in string.h
the way glibc does
The build error can be reproduced with the following minimal defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_DBUS=y
BR2_PACKAGE_OPENSCAP=y
Backport the upstream fix to allow openscap to build with such
configuration. The custom patch can be removed once openscap is
re-released on its branch 1.3.x.
The issue affects master, 2026.05.x and 2025.02.x
Fixes: https://autobuild.buildroot.org/results/a874d4f34d36fa9f8566be90ad2d5facb99aec24/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
host-erlang build can fail with the following error:
make[5]: Nothing to be done for 'opt'.
MAKE opt
CC ../priv/bin/x86_64-pc-linux-gnu/odbcserver
/usr/bin/ld: ../priv/obj/x86_64-pc-linux-gnu/odbcserver.o: in function `encode_column_dyn':
odbcserver.c:(.text+0x6b4): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6c2): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x6d4): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6e7): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x6fa): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x708): undefined reference to `ei_x_encode_tuple_header'
/usr/bin/ld: odbcserver.c:(.text+0x71b): undefined reference to `ei_x_encode_ulong'
/usr/bin/ld: odbcserver.c:(.text+0x72e): undefined reference to `ei_x_encode_ulong'
[...]
This can be reproduced with the following minimal defconfig (and
libei.so present on host, see details below):
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_ERLANG=y
Those missing symbols are part of the erl_interface, exposed by libei.a.
host-erlang builds correctly libei.a _before_ odbcserver.c (it can be
found in lib/erl_interface/obj/x86_64-pc-linux-gnu/libei.a), but the
failure is actually due to the build command generated and used for
odbcserver.c, especially the link arguments:
/usr/bin/gcc \
[...]
-o ../priv/bin/x86_64-pc-linux-gnu/odbcserver \
../priv/obj/x86_64-pc-linux-gnu/odbcserver.o \
-L/usr/lib64 \
-lodbc \
-L/home/alexis/src/buildroot/erlang-master/build/host-erlang-custom/lib/erl_interface/obj/x86_64-pc-linux-gnu \
-lpthread -lei
/usr/lib64 is searched before the path where libei.a has been built, so
if whether a valid libei.a or libei.so is found there, it shadows the
expected libei.a. In the build from which the logs above come, the
notable point is that the host system indeed have a valid libei.so, but
is completely unrelated to erl_interface; it rather exposes the Emulated
Input protocol aimed at Wayland stack; and so it obviously contains none
of the expected ei_* symbols.
Upstream has already identified and fixed the issue, the fix is already
released in versions >= 27.x.y. Erlang 26 (the version currently
packaged in buildroot), isn't supported anymore (only the three latest
releases are supported, see
https://github.com/erlang/otp/blob/master/SECURITY.md), so there won't
be any new minor update that will release this fix.
Pick and backport the fixing patch so that the current version packaged
in buildroot can still build.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The VERSAL2_CONSOLE variable does not actually exist when building the atf
with plat=versal2. So the current VERSAL2_CONSOLE=cadence1 is not actually
doing anything. For this reason, the atf will print on its default console
which is UART0 or pl011_0.
The correct definition would be CONSOLE=pl011_1 in order to build the atf to
print on UART1 or pl011_1.
However, the git repo xparameters.h of the versal2_plm is not currently
enabling UART1 because the XPAR_XUARTPSV_NUM_INSTANCES is set to 1 including
the address defines only for UART0.
97f2baf7f6/lib/sw_apps/versal_plm/misc/versal_2ve_2vm/xparameters.h (L1519)
The problem with this is that the plm is not configuring UART1, so the atf
will crash at boot time, if it is built with CONSOLE=pl011_1 and the plm has
not already enabled UART1.
For now, we will remove the unnecessary config that is doing nothing. The
versal2_vek385_defconfig is working, but users need to currently open two
console windows to see the boot log because the current config is the
following.
plm - console uart0
asufw - console uart0
atf - console uart0
optee-os - console uart1
u-boot - console uart1
Linux - console uart1
A patch has been submitted to the embeddedsw repo to fix the xparameters.h
file such that the plm will correctly enable UART1. Once this is applied, we
will configure the plm and atf to use UART1 with the versal2_vek385_defconfig.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://github.com/strukturag/libheif/releases/tag/v1.23.2
Fixes the following CVEs:
(CVE numbers will be added upstream when assigned.)
CVE-2026-XXXXX (GHSA-g89c-p67h-r497)
Heap buffer overflow in scale_nearest_neighbor() via duplicate alpha
planes from nested iden/auxl items. (critical)
(GHSA-2jg2-4ch7-h545)
Out-of-bounds read and write in derived-item and pixel-plane handling.
Through iden and auxl item chains, a crafted file could attach pixel
planes whose size differs from the image geometry; crop, scale, and
plane-extraction code then indexed those planes with the wrong size.
A working code-execution exploit was confirmed. Plane sizes are now
validated wherever they are consumed. (critical)
CVE-2026-XXXXX (GHSA-24wx-9w62-c96w)
brotli/zlib decompression of mime metadata and unci image data had no
effective output-size limit, so a decompression bomb could exhaust
memory. Decompressed output is now bounded by the security limits.
(high)
CVE-2026-XXXXX (GHSA-x8xm-cm2c-cfc8)
Chains of derived-image references (grid, iovl, iden) bypassed decode
caching and memory limits, causing CPU and memory amplification. (high)
CVE-2026-XXXXX (GHSA-xw34-mjcp-jqh8)
Sequence sample-timing initialization could produce non-terminating
decode loops and unbounded memory, bypassing max_sequence_frames.
(high)
CVE-2026-XXXXX (GHSA-j264-xvrp-5v7q)
Out-of-bounds write in the unci encoder when
heif_context_add_image_tile() is given a tile whose planes do not match
its declared size. (high)
CVE-2026-XXXXX (GHSA-p58j-h3vm-3fp5)
Heap out-of-bounds read in the inline-mask region API when
mask_data_len does not match the region geometry. (medium)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump of libxml2 from 2.13.8 to 2.15.0 in Buildroot commit
d81922c1ef, the "virt" plugin of
collectd no longer builds:
src/virt.c:2208:49: error: expected ';', ',' or ')' before 'ATTRIBUTE_UNUSED'
2208 | static void virt_eventloop_timeout_cb(int timer ATTRIBUTE_UNUSED,
| ^~~~~~~~~~~~~~~~
src/virt.c: In function 'register_event_impl':
src/virt.c:2221:26: error: 'virt_eventloop_timeout_cb' undeclared (first use in this function)
2221 | virt_eventloop_timeout_cb, NULL, NULL) < 0) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
src/virt.c:2221:26: note: each undeclared identifier is reported only once for each function it appears in
This is due to the fact that the virt plugin code was incorrectly
using the ATTRIBUTE_UNUSED define, which was supposed to be an
internal define of libxml2. But it turns out that up to libxml2 2.14.0
and its commit 208f27f9641a59863ce1f7d4992df77f7eb0ea9d, this define
had been made publicly available. It could therefore mistakenly be
used by collectd's virt plugin... until libxml2 was upgraded.
We backport an upstream patch from collectd that fixes the issue.
Fixes:
https://autobuild.buildroot.net/results/4c8463f0372560f4c3a20b0f67854460f0d1c400/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds a simple bpftrace test that ensures that not only it
builds fine, but it also runs properly on a minimal test scenario.
Assisted-by: GPT-5.6
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Julien:
- reindent emulator.boot() options
- add a call to "bpftrace --version"
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Buildroot commit 25cb3813e7 which
bumped LLVM from 21.x to 22.x, the build of bpftrace is broken as
bpftrace 0.24.2 only supports LLVM up to 21.
We tried backporting the bpftrace patch that allows using LLVM up to
version 22 but the patch didn't apply cleanly but more importantly it
wasn't clear if this patch was sufficient. Therefore, we opt for
bumping bpftrace entirely to fix the issue.
Packaging changes:
- The new version of bpftrace no longer needs host-bison/host-flex,
because bpftrace is now using a handwritten parser.
- Pass -DUSE_SYSTEM_LIBBPF:BOOL=ON to ensure the system libbpf version
is used, and not the bundled version
- Now depends on kernel headers >= 5.10 because it needs CAP_BPF and
CAP_PERFMON
Upstream changelog:
https://github.com/bpftrace/bpftrace/blob/v0.26.1/CHANGELOG.md
Fixes:
https://autobuild.buildroot.net/results/a3e3fd696685864977c688aa11c2653357cf6207/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Julien: add link to upstream changelog]
Signed-off-by: Julien Olivain <ju.o@free.fr>
bpftrace often needs very recent kernel headers, more recent than the
runtime version actually needed. We already had a workaround in
libbpf making sure that if the kernel headers are older than 6.1, we
would install the libbpf provided headers instead.
As we are about to update bpftrace to a newer version that uses
BPF_TRACE_KPROBE_SESSION, which was introduced in Linux 6.10, we need
to update this workaround accordingly and ensure that the libbpf
header is installed if the kernel headers are older than 6.10.
This is necessary for the update of bpftrace to 0.26.1.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since commit
566bdcb97f ("package/fluidsynth:
security bump to version 2.5.7"), fluidsynth tries to download some
"gcem" code during its configure step, which not only violates
Buildroot's policies, but also breaks the build if network is not
available during the build.
To fix this, we add an EXTRA_DOWNLOADS to grab gcem and extract it at
the right place. Some minor fix (submitted upstream) is needed to
ensure the FindGCEM.cmake logic properly finds that gcem is already in
the source tree.
Fixes:
https://autobuild.buildroot.net/results/048df28f6ab97a16731e62d7f56c6eba565cda63/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Based on the lighttpd test case. Verify that we can download index.html
from haproxy in front of lighttpd.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
haproxy has a runtime test to verify that it is built with -fwrapv:
haproxy
FATAL ERROR: invalid code detected -- cannot go further, please recompile!
The source code was miscompiled by the compiler, which usually indicates that
some of the CFLAGS needed to work around overzealous compiler optimizations
were overwritten at build time. Please do not force CFLAGS, and read Makefile
and INSTALL files to decide on the best way to pass your local build options.
Build options :
TARGET = custom
CPU = generic
CC = /home/peko/source/buildroot/output-haproxy/host/bin/arm-linux-gcc
CFLAGS = -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
OPTIONS = USE_THREAD=1 USE_DL=1
DEBUG = -DDEBUG_STRICT -DDEBUG_MEMORY_POOLS
Which comes from:
https://github.com/haproxy/haproxy/blob/v2.6.0/src/haproxy.c#L3008-L3037
So build it with -fwrapv to fix that.
Notice that this message also embeds the build path (through CC), breaking
reproducible builds.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since upstream commit
e42e3193137d1b21e84b499336e7a8887b8a8689 ("intel: add Jay"), a C23
construct is used in the intel driver code:
enum jay_predication : uint8_t
This causes a build issue with GCC < 13:
In file included from ../src/intel/compiler/jay/jay_builder.h:12,
from ../src/intel/compiler/jay/jay_from_nir.c:23:
../src/intel/compiler/jay/jay_ir.h:582:22: error: expected identifier or ‘(’ before ‘:’ token
582 | enum jay_predication : uint8_t {
| ^
../src/intel/compiler/jay/jay_ir.h:637:25: error: field ‘predication’ has incomplete type
637 | enum jay_predication predication;
| ^~~~~~~~~~~
We fix that by integrating a patch already available in
OpenEmbedded. It changes the code to not use the C23 construct.
This build issue was encountered on host-mesa3d while building an
allyespackageconfig configuration inside our standard Docker
container.
Buildroot commit
c073c97617 ("package/{mesa3d,
mesa3d-headers}: bump version to 26.1.0") that switched to mesa3d
26.1.0, which contains the problematic commit. Therefore 2026.05 is
affected, but not earlier Buildroot versions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
perl does not build with musl due to memrchr() being unavailable. This
is caused by a perl-cross bug, which does function availability
detection with _GNU_SOURCE defined, but then does the build without
_GNU_SOURCE defined. At least OpenEmbedded and NixOS have faced the
same issue, and worked it around in slightly different ways.
On our side, we create a patch, which was submitted upstream, to solve
the issue.
This issue has been introduced in perl-cross commit b40c560f5d5e,
which was first merged in perl-cross release 1.4.1. From a Buildroot
perspective, we bumped from perl-cross 1.4 to 1.4.1 in commit
8a289667f5, which was merged
2023.05. And indeed the build failure can be reproduced even on our
LTS 2025.02.x, so the fix needs to be backported there.
It should be noted that even if the patch is against perl-cross, we
add it to package/perl/ directly, as patches in perl are applied after
perl has been extracted *and* perl-cross has been extracted on top.
Fixes:
https://autobuild.buildroot.net/results/3e47ade0963642988fd8e1be9a6e8042700619ec/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump of autoconf to version 2.73 in Buildroot commit, the
build of target bind fails if the host compiler is too old, because
the bind build system tries to use -std=gnu23 when building host tools
which isn't supported by older GCC releases, causing:
checking whether the C compiler works... no
configure: error: in '/home/thomas/autobuild/instance-2/output-1/build/bind-9.20.26':
configure: error: C compiler cannot create executables
See 'config.log' for more details
make: *** [package/pkg-generic.mk:263: /home/thomas/autobuild/instance-2/output-1/build/bind-9.20.26/.stamp_configured] Error 77
To fix this, we backport a number of patches from autoconf-archive, to
fix the m4/ax_prog_cc_for_build.m4 macro file, so that it works with
autoconf 2.73.
OpenEmbedded has a similar fix:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/bind/bind/0001-m4-Backport-ax_prog_cc_for_build.m4-macros.patch
but did not backport as carefully the autoconf-archive commits (and
their commit message reverts to sudo).
The patches can be dropped when we update to a newer version of bind
that itself has an updated copy of the m4/ax_prog_cc_for_build.m4
file.
Fixes:
https://autobuild.buildroot.net/results/13e07755101b7cae2f84eef173ef752f92842e71/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The BR2_PACKAGE_QT6DECLARATIVE_QUICK option has some logic to select
network support in host-qt6base if network support is enabled in
qt6base. However, it turns out that this is actually required at the
top level BR2_PACKAGE_QT6DECLARATIVE option: as soon as network
support is available in qt6base, the qt6declarative build will assume
that qmlprofiler is available... but that requires network support in
host-qt6base.
This fixes the following build failure:
CMake Error at /home/thomas/autobuild/instance-2/output-1/build/qt6base-6.9.1/cmake/QtToolHelpers.cmake:784 (message):
Failed to find the host tool "Qt6::qmlprofiler". It is part of the
Qt6QmlTools package, but the package did not contain the tool. Make sure
that the host module Qml was built with all features enabled (no explicitly
disabled tools).
Call Stack (most recent call first):
/home/thomas/autobuild/instance-2/output-1/build/qt6base-6.9.1/cmake/QtToolHelpers.cmake:83 (qt_internal_find_tool)
tools/qmlprofiler/CMakeLists.txt:11 (qt_internal_add_tool)
Fixes:
https://autobuild.buildroot.net/results/72c956fdf982382d2981c649c456d1edc2c9d6b2/
We did not trace back exactly since when the problem exists, but we
verified that the problem exists in 2025.02.x. It can be reproduced
with the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_NETWORK=y
BR2_PACKAGE_QT6DECLARATIVE=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The commit "Enable host test module to ensure that qmltestrunner is
built" in qt6declarative's Config.in feels lonely under
BR2_PACKAGE_QT6DECLARATIVE. It's because it's actually related to a
select done in the sub-option BR2_PACKAGE_QT6DECLARATIVE_QUICK, so
move it there.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Firewalld v2.4.3 [1] firewall-cmd added a new log line while
waiting for dbus connection [2].
[BRTEST# firewall-cmd --state
Waiting on dbus connection...
running
The line "Waiting on dbus connection..." is not always printed by
firewall-cmd, so we have to search explicitely for the expected
string to get a reproducible test result.
Update both TestFirewalld accordingly.
This change is required to fix:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152329 (TestFirewalldSysVInit)
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152332 (TestFirewalldSystemd)
[1] 380dd8a348
[2] 5e1c37c966
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In Glib >= 2.88, GLib.unix_signal_add has been moved to a separate
platform-specific library. This break backward compatibility from
GLib-2.0. A workaround has been applied to pygobject >= 3.55.3
74e4e0f40a
This issue currently break TestFirewalldSysVInit and
TestFirewalldSystemd runtime tests since the bump to glib 2.88.3 [1]:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152329 (TestFirewalldSysVInit)
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152332 (TestFirewalldSystemd)
Break the test TestPythonPy3Gobject now in order to reproduce the same
issue than for Firewalld test.
[1] e313a2d259
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The mdnsd runtime test can randomly fail on slow runners.
It's hard to reproduce locally (only one failure after a few attempts)
but we can reproduce it easily by removing the while loop entirely.
It means that the "sleep 1" is not used on the Gitlab runner.
The timestamp of the failed job seems to confirm that [1].
07:06:55 [BRTEST# while ! ifconfig eth0 | grep -q 'inet addr'; do sleep 1; done
07:06:55 [BRTEST# echo $?
07:06:55 0
07:06:55 [BRTEST# mquery -T _http._tcp |grep -F buildroot._http._tcp.local
07:06:55 [BRTEST# echo $?
07:06:55 1
So wait a bit for mdnsd to be ready.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152862
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit [1] (package/apache: use "Debian" filesystem
layout to fix read-only rootfs) changed the filesystem layout.
This had the effect of installing files to different locations
and breaking the test_php runtime test.
This commit fixes the issue by updating the file paths to their
right locations. The "httpd.conf" was updated by following the
same recipe described in the comment (starting from a config
file as installed by the apache Buildroot package).
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16060152979
[1] 1006666f67
Signed-off-by: Julien Olivain <ju.o@free.fr>
Tested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the bump of autoconf to version 2.73 in Buildroot commit [1], the
build of target flex fails if the host compiler is too old, because
the flex build system tries to use -std=gnu23 which isn't supported by
older GCC releases, causing:
gcc: error: unrecognized command-line option '-std=gnu23'; did you mean '-std=gnu2x'?
gcc: error: unrecognized command-line option '-std=gnu23'; did you mean '-std=gnu2x'?
make[3]: *** [Makefile:1162: stage1flex-buf.o] Error 1
(Indeed the *target* flex package does build some host tools using the
host GCC compiler.)
To fix this issue, we backport an upstream commit that isn't yet in
any flex release.
Fixes:
https://autobuild.buildroot.net/results/aac730b57adb5b54964f1054de781750952ef7d4/
[1] a6e8c07a33
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Julien: add link to commit]
Signed-off-by: Julien Olivain <ju.o@free.fr>
In commit 54f96add94 ("package/bind:
security bump version to 9.20.24") the depends on
BR2_TOOLCHAIN_HAS_THREADS_NPTL was incorrectly downgraded to
BR2_TOOLCHAIN_HAS_THREADS:
- depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # libuv
+ depends on BR2_TOOLCHAIN_HAS_THREADS # liburcu, libuv
This is wrong because libuv depends on
BR2_TOOLCHAIN_HAS_THREADS_NPTL. This causes unmet dependencies:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBUV
Depends on [n]: BR2_TOOLCHAIN_HAS_THREADS_NPTL [=n] && BR2_USE_MMU [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_HAS_SYNC_4 [=y] && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 [=y]
Selected by [y]:
- BR2_PACKAGE_BIND [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_SYNC_4 [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && BR2_INSTALL_LIBSTDCPP [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 [=y] && BR2_PACKAGE_LIBURCU_ARCH_SUPPORTS [=y]
Fix that by switching back to the BR2_TOOLCHAIN_HAS_THREADS_NPTL
dependency.
Fixes: 54f96add94 ("package/bind: security bump version to 9.20.24")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
- CVE-2026-19654:
A unauthenticated remote peer may lead rsyslogd to crash due to a flaw
in the optional imptcp module. A crafted input sequence during
oversize-frame recovery can cause an invalid internal message length
and terminate rsyslogd. No confidentiality or integrity impact,
privilege escalation, or code execution has been identified. imtcp and
the default imptcp framing modes are not affected.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-19654
- 07b3c40a5a
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
See the changelog:
- https://nlnetlabs.nl/projects/unbound/download/#unbound-1-25-2
It fixes the following vulnerabilities:
- CVE-2026-14586: Assertion in libngtcp2 when under pressure in high
concurrency DNS-over-QUIC environments.
- CVE-2026-32665: Remote DNS-over-QUIC denial of service due to
`quic-size` budget bypass.
- CVE-2026-40691: Packet of death for DNSCrypt over TCP.
- CVE-2026-41637 Degradation of resolution service from improperly
accounted client-terminated DNS-over-QUIC queries.
- CVE-2026-42955: Extra fix for CVE-2026-40622 to also clamp the TTL of
A/AAAA records disallowing a one-time 'ghost domain' delegation
renewal via glue records.
- CVE-2026-44621: Libunbound applications configured with
'unwanted-reply-threshold' could eventually be abruptly terminated.
- CVE-2026-44687: Off-by-one error in 'harden-below-nxdomain' logic can
shadow a stub/forward zone by a legitimate parent's NXDOMAIN.
- CVE-2026-44690: Cross-zone wildcard cache poisoning via RRSIG.labels
manipulation.
- CVE-2026-46582: A wildcard replay, as another piece of data, triggers
poisoning in the serve expired reply path.
- CVE-2026-50045: 'max-global-quota' reset by DNSSEC validation
restarts.
- CVE-2026-50046: Possible heap use-after-free in an error path when a
DoT forwarded query is jostled out.
- CVE-2026-50243: 'response-ip'/'rpz' can rewrite BOGUS answers instead
of returning SERVFAIL.
- CVE-2026-50248: BOGUS configured primary hostname accepted for XFR in
auth/rpz zones.
- CVE-2026-50251: Attacker supplied `0.0.0.0`/`::` glue triggers
defensive full-cache flush.
- CVE-2026-50252: Possible cache poisoning attack by mapping source port
population per thread.
- CVE-2026-52863: Memory corruption could lead to crash and denial of
service.
- CVE-2026-54478: DNS Cookie bypass when combined with proxy-protocol
use.
- CVE-2026-55708: Privacy/configuration issue when adding local data in
views through 'unbound-control'.
- CVE-2026-55717: 'serve-expired-client-timeout' and 'response-ip' CNAME
redirect could lead to a crash.
- CVE-2026-55973: 'dns-error-reporting: yes' leads to stack buffer
overflow.
- CVE-2026-55990: Packet of death for a DNSCrypt misconfigured Unbound.
- CVE-2026-55991: Remote DNS-over-QUIC (DoQ) flow-control assertion
failure in libngtcp2.
- CVE-2026-56416: Possible heap buffer overflow when validator
canonicalizes RDATA that contains domain name.
- CVE-2026-56444: Degradation of resolution service when
'discard-timeout' and 'serve-expired-client-timeout' are combined in
unusual configuration.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This release includes a broad round of hardening against malformed and
adversarial input across the Python SDK (bounding allocations and enforcing
decompression limits before trusting size fields read from the input).
See the release notes https://avro.apache.org/blog/2026/08/12/avro-1.12.2/
Also update the download url, because www-eu.apache.org/dist/...
is a redirection to downloads.apache.org/...
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/openssl/openssl/releases/tag/openssl-3.6.4
This release incorporates the following bug fixes and mitigations:
Fixed QUIC server being able to trigger double free when processing
INITIAL packet.
(CVE-2026-18798)
Fixed heap buffer overflow in CMS key unwrapping.
(CVE-2026-63072)
Fixed invalid pointer dereference in CMP server via crafted protectionAlg.
(CVE-2026-63076)
Fixed unbounded memory growth in QUIC server incoming channel queue.
(CVE-2026-14456)
Fixed RPK server signature algorithm selection being able to dereference
a missing certificate.
(CVE-2026-14457)
Fixed excessive memory use buffering DTLS records for a future epoch.
(CVE-2026-54874)
Fixed client-side memory leak in OCSP response checking.
(CVE-2026-54876)
Fixed untrusted Sender DN being used as a format string in CMP response
validation.
(CVE-2026-63073)
Fixed CMP indefinite cache growth of extraCerts.
(CVE-2026-63074)
Fixed QUIC ACK-only packet retention being able to cause memory exhaustion.
(CVE-2026-63075)
Fixed possibility of AEAD forgeries with empty ciphertext when using
EVP_Cipher().
(CVE-2026-75803)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In some situations (old Linux <3.17 or glibc <2.25), expat fail at
compilation time with the error:
xmlparse.c:150:4: error: #error You do not have support for any sources of high quality entropy enabled.
For end user security, that is probably not what you want. Your options include:
* Linux >=3.17 + glibc >=2.25 (getrandom): HAVE_GETRANDOM,
* Linux >=3.17 + glibc (including <2.25) (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM,
* BSD / macOS >=10.7 / glibc >=2.36 (arc4random_buf): HAVE_ARC4RANDOM_BUF,
* BSD / macOS (including <10.7) / glibc >=2.36 (arc4random): HAVE_ARC4RANDOM,
* BSD / macOS >=10.12 / glibc >=2.25 (getentropy): HAVE_GETENTROPY,
* Linux (including <3.17) / BSD / macOS (including <10.7) / Solaris >=8 (/dev/urandom): XML_DEV_URANDOM,
* Windows >=Vista (rand_s): _WIN32.
If you insist on not using any of these, bypass this error by defining XML_POOR_ENTROPY and be vulnerable to hash flooding;
you have been warned. If you have reasons to patch this detection code away or need changes to the build system, please open a bug. Thank you!
This is caused by the upstream commit [1] "Autotools: Stop using
/dev/urandom by default", first included in expat 2.8.2. The
Buildroot expat package was bumped to that version in commit [2].
But since all Linux systems have /dev/urandom, we can just enable
it by default.
Note: this commit does not globally switch the entropy source to
/dev/urandom. It is rather enabling it in the list of available
sources. On more recent Linux systems (linux >= 3.17, glibc >= 2.25),
other sources will be chosen. The entropy source preference order
amongst the enabled sources is defined in [3].
This commit also changes the _CONF_OPTS to multiline layout to fit
within the 80 characters.
[1] d30eca113a
[2] 6b1f6f7a48
[3] https://github.com/libexpat/libexpat/blob/R_2_8_3/expat/lib/xmlparse.c#L1115-L1142
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
[Julien: add extra info in the commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since gdb 9.x, gdb can optionally use the xxhash library. Since we
currently don't do anything about it, it's a potential "silent"
dependency.
In particular, for host-gdb, this means host-gdb might end up being
linked with the system-provided xxhash library if available.
This patch handles this dependency:
- For the target package, by looking at the value of
BR2_PACKAGE_XXHASH
- For the host package, by looking at the value of a newly introduced
BR2_PACKAGE_HOST_GDB_XXHASH
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For target gdb, we properly enable/disable lzma support depending on
BR2_PACKAGE_XZ.
However, for host-gdb we don't do anything, which can lead the gdb
configure script to detect and use a system-provided xz library, which
is not desired.
Instead, add an explicit option BR2_PACKAGE_HOST_GDB_LZMA, which when
enabled pulls in host-xz, but also when disabled ensures gdb doesn't
try to use a system-provided xz library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add the option to configure the atf to load the optee-os binary:
BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
Without this, everything was still booting, and even though the versal2_plm
was loading the optee-os to its runtime location, it was never actually
loaded by the atf.
With this option enabled, atf is now properly loading optee with the boot log
below.
NOTICE: BL31: Executing from 0xbbf00000
NOTICE: BL31: Secure code at 0x1800000
NOTICE: BL31: Non secure code at 0x40000000
NOTICE: BL31: v2.14.0(release):custom
NOTICE: BL31: Built : 08:41:36, Aug 25 2026
KATs execution completed.
In task dispatch loop
I/TC:
I/TC: Non-secure external DT found
I/TC: pl011: device parameters ignored (115200n8)
I/TC: Switching console to device: /axi/serial@f1930000
I/TC: OP-TEE version: Unknown_4.9 (gcc version 14.3.0 (Buildroot 2021.11-18033-g83947c7bb6)) #1 Mon Aug 24 08:45:53 UTC 2026 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: Cluster shift early-configured: 1 (cores per cluster: 2)
I/TC: ASU initialization complete
I/TC: OP-TEE OS Running on Platform AMD Versal Gen 2
I/TC: ASU ECC: NIST_P192=SW NIST_P224=SW NIST_P256=HW
I/TC: ASU ECC: NIST_P384=SW NIST_P521=SW
I/TC: ASU RSA driver successfully initialized
I/TC: Primary CPU switching to normal world boot
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit a2380157f6 ("toolchain: enable
libquadmath for PowerPC with VSX"), the definition of
BR2_TOOLCHAIN_HAS_LIBQUADMATH has been extended to also be true when
BR2_POWERPC_CPU_HAS_VSX.
However, practical experiments show that when 64-bit VSX-capable cores
are used in 32-bit mode, libquadmath is not built by GCC, causing
build failures:
cp: cannot stat '/home/autobuild/autobuild/instance-3/output-1/host/powerpc-buildroot-linux-musl/lib*/libquadmath*': No such file or directory
We did an extensive testing, building the 27 combinations of:
- GCC versions: 14, 15, 16
- C library: glibc, uclibc, musl
- PowerPC 32-bit, PowerPC 64-bit, PowerPC 64-bit little endian
This testing provides the following results:
| gcc14 | powerpc64 | glibc | OK |
| gcc14 | powerpc64le | glibc | OK |
| gcc14 | powerpc64le | musl | OK |
| gcc14 | powerpc64le | uclibc | SKIPPED |
| gcc14 | powerpc64 | musl | OK |
| gcc14 | powerpc64 | uclibc | SKIPPED |
| gcc14 | powerpc | glibc | FAILED |
| gcc14 | powerpc | musl | FAILED |
| gcc14 | powerpc | uclibc | FAILED |
| gcc15 | powerpc64 | glibc | OK |
| gcc15 | powerpc64le | glibc | OK |
| gcc15 | powerpc64le | musl | OK |
| gcc15 | powerpc64le | uclibc | SKIPPED |
| gcc15 | powerpc64 | musl | OK |
| gcc15 | powerpc64 | uclibc | SKIPPED |
| gcc15 | powerpc | glibc | FAILED |
| gcc15 | powerpc | musl | FAILED |
| gcc15 | powerpc | uclibc | FAILED |
| gcc16 | powerpc64 | glibc | OK |
| gcc16 | powerpc64le | glibc | OK |
| gcc16 | powerpc64le | musl | OK |
| gcc16 | powerpc64le | uclibc | SKIPPED |
| gcc16 | powerpc64 | musl | OK |
| gcc16 | powerpc64 | uclibc | SKIPPED |
| gcc16 | powerpc | glibc | FAILED |
| gcc16 | powerpc | musl | FAILED |
| gcc16 | powerpc | uclibc | FAILED |
The "SKIPPED" are when the configuration is not possible: uClibc
doesn't support powerpc64 or powerpc64le.
Then, as we can see, the build fails for all "powerpc"
configuration. Our conclusion is therefore that libquadmath is not
supported on PowerPC 32-bit. While we were not able to find direct
evidence in the gcc code base, this practical experiment shows that is
simply doesn't work on PowerPC 32-bit.
So, we take the logical action of adjusting
BR2_TOOLCHAIN_HAS_LIBQUADMATH so that it is true only on
powerpc64/powerpc64le.
Fixes:
https://autobuild.buildroot.org/results/46d435c9f5086a8695f4f6cd4026bb0d194de13c/
Cc: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
