Fixes the following security issue:
- CVE-2025-58050: PCRE2: heap-buffer-overflow read in match_ref due to
missing boundary restoration in SCS
Compared to 10.45, this release has only a minimal code change to prevent a
read-past-the-end memory error, of arbitrary length. An attacker-controlled
regex pattern is required, and it cannot be triggered by providing crafted
subject (match) text. The (*ACCEPT) and (*scs:) pattern features must be
used together.
Release 10.44 and earlier are not affected.
https://github.com/PCRE2Project/pcre2/security/advisories/GHSA-c2gv-xgf5-5cc2https://www.cve.org/CVERecord?id=CVE-2025-58050
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: add link to CVE in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9fd06f212a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The last mariadb version bump [1] added -DHAVE_SYSTEM_LIBFMT_EXITCODE=0
to workaround cross-compiling issue during libfmt cmake check.
But it actually requies at least cmake >= 3.30 to work.
Indeed, our docker image used by Gitlab-CI uses cmake 3.25.1 and
segfault while testing for libfmt.
-- Performing Test HAVE_SYSTEM_LIBFMT
/bin/bash: line 1: 163369 Segmentation fault
$ cmake --version
cmake version 3.25.1
Using the same TestPerlDBDmysql configuration locally with
cmake 3.30.8 installed build fine.
Looking at cmake cmTryRunCommand.cxx history from 3.30.x show that
several fixes about cross-compiling isses were applied to cmake 3.26.x
[2] probably solving the issue. Requires BR2_HOST_CMAKE_AT_LEAST_3_30
for now, since only cmake 3.30.8 installed locally was tested.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124486 (TestPerlDBDmysql)
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124439 (TestMariaDB)
[1] 6cd8f95346 ("package/mariadb: bump version to 10.11.11")
[2] https://gitlab.kitware.com/cmake/cmake/-/commits/v3.30.9/Source/cmTryRunCommand.cxx?ref_type=tags
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit de9c0f971c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
xlib_xtrans clients (for example xserver_xorg-server) are failing to
compile with gcc 15.1.0.
The issue can be reproduced with the commands:
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
EOF
make olddefconfig
make xserver_xorg-server
which outputs the compilation error:
auth.c: In function 'GenerateRandomData': auth.c:320:5: warning:
ignoring return value of 'read' declared with attribute
'warn_unused_result' [-Wunused-result] 320 | read(fd, buf, len);
| ^~~~~~~~~~~~~~~~~~ In file included from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/string.h:548,
from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xos.h:62,
from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtrans.h:54,
from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtransint.h:79,
from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/transport.c:55,
from xstrans.c:17: In function 'strncpy', inlined from
'_XSERVTransGetHostname' at
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtrans.c:1351:5,
inlined from '_XSERVTransConvertAddress' at
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtransutil.c:188:12:
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/bits/string_fortified.h:100:10:
error: '__builtin_strncpy' offset [130, 319] from the object at 'name'
is out of the bounds of referenced subobject 'nodename' with type
'char[65]' at offset 65 [-Werror=array-bounds=] 100 | return
__builtin___strncpy_chk (__dest, __src, __len, |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 101 |
__glibc_objsize (__dest)); |
~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/X11/Xtrans/Xtransint.h:105:
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/sys/utsname.h:
In function '_XSERVTransConvertAddress':
/home/wbx/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/include/sys/utsname.h:54:10:
note: subobject 'nodename' declared here 54 | char
nodename[_UTSNAME_NODENAME_LENGTH]; | ^~~~~~~~ cc1: some
warnings being treated as errors make[2]: *** [Makefile:696: xstrans.lo]
Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving
directory
'/home/wbx/buildroot/output/build/xserver_xorg-server-21.1.18/os'
make[1]: *** [Makefile:796: all-recursive] Error 1 make[1]: Leaving
directory '/home/wbx/buildroot/output/build/xserver_xorg-server-21.1.18'
make: *** [package/pkg-generic.mk:273:
/home/wbx/buildroot/output/build/xserver_xorg-server-21.1.18/.stamp_built]
Error 2
The update fixes the compile error.
See here for changes:
https://lists.x.org/archives/xorg/2025-March/061900.html
The COPYRIGHT was updated from 2005 to 2025.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Julien: add commands to reproduce the issue]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8c539854dd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Using /dev/null as file source because the package doesn't provide a default
systemv service configuration file.
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
[Julien: remove S43htpdate .checkpackageignore entry
to fix check-package error
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1f2b459b56)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The symlink bin/lld -> $(GNU_TARGET_NAME)/bin/lld is broken inside a
SDK containing host-lld package. The symlink still points to the
location of lld inside the build's host folder instead of the location
of lld inside the SDK. In consequence GCC is not able to find lld
linker. Changing the symlink to be relative during host-lld
installation fixes the problem.
Signed-off-by: Victor Krawiec <victor.krawiec@arturia.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 289dd6bd76)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Without systemd package/docker-engine requires another way to mount
/sys/fs/cgroup, so far provided by BR2_PACKAGE_CGROUPFS_MOUNT for
cgroup v1. Replace this with BR2_PACKAGE_CGROUPFS_V2_MOUNT for cgroup
v2 support. 5.2 is the minimum recommended version for cgroup v2
support according to the Docker documentation: "v4.15 or later (v5.2
or later is recommended)" [1].
Depending on the selected container runtime users may need to adjust
kernel configurations to enable options required by that runtime with
cgroup v2 (e.g. CONFIG_CGROUP_BPF for runc).
Propagate dependencies accordingly: The Docker btrfs filesystem driver
does not need a separate and lower minimum headers version,
package/mender-update-modules needs to apply the new "depends on".
[1] https://docs.docker.com/engine/containers/runmetrics/#running-docker-on-cgroup-v2
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit b07b0bb456)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since commit 947dbc92a2 the Bootlin
stable toolchain uses headers 5.4, which can lead to build outputs
incompatible with older kernels. Update to the latest 5.4 kernel to
avoid this. The kernel config is updated according to the requirements
of current Docker, runc, and crun.
Additionally switch the CPU of the test VM to Haswell, to avoid
dockerd failing to start with a "This program can only be run on AMD64
processors with v3 microarchitecture support" error.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit efe00fb3fb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
php-lua fails to build in buildroot 2025.08-rc3 on the following error:
in file included from [...]/usr/include/php/Zend/zend.h:32,
from [...]/usr/include/php/main/php.h:31,
from [...]/build/php-lua-2.0.7/lua.c:24:
[...]/build/php-lua-2.0.7/lua.c: In function ‘php_lua_write_property’:
[...]/build/php-lua-2.0.7/lua.c:247:37:
error: ‘val’ undeclared (first use in this function); did you mean
‘zval’?
247 | lua_pushlstring(L, ZSTR_VAL(val), ZSTR_LEN(val));
| ^~~
[...]/usr/include/php/Zend/zend_string.h:66:26:
note: in definition of macro ‘ZSTR_VAL’
66 | #define ZSTR_VAL(zstr) (zstr)->val
| ^~~~
[...]/build/php-lua-2.0.7/lua.c:247:37:
note: each undeclared identifier is reported only once for each function
it appears in
247 | lua_pushlstring(L, ZSTR_VAL(val), ZSTR_LEN(val));
| ^~~
[...]/usr/include/php/Zend/zend_string.h:66:26:
note: in definition of macro ‘ZSTR_VAL’
66 | #define ZSTR_VAL(zstr) (zstr)->val
| ^~~~
make[2]: *** [Makefile:214: lua.lo] Error 1
The issue triggers only if lua interpreter version is lower than 5.2. In
this case, php_lua_write_property calls ZSTR_VAL on the wrong variable.
Fix php-lua build by calling ZSTR_VAL on the correct variable.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124501 (TestPhpLuaLuajit)
Suggested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Romain: add link to failing TestPhpLuaLuajit]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit a1daf153bf)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The git.ti.com cgit server continues to be plagued with reliability
issues which are reportedly from heavy bot traffic. To combat this the
system administrators have removed the archived downloads feature from
this server.
Switch to TI's Github mirror so new downloads continue to be possible.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ebf0131e3e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the bump to Python 3.13.2 in commit
d63e207eb8, there is a runtime assertion
in Python when the toolchain doesn't support time64 [1]. The only such
toolchain is one with uClibc and linux headers < 5.1.
Encoding this dependency in Config.in was deemed to complicated (cfr.
commit ffd0028031).
Instead, do a build-time check of the same condition. The check itself
is a bit complicated, but it is localized to python3.mk and doesn't need
to be propagated to all reverse dependencies.
Testing such a corner case toolchain is a bit complicated. It can be
done with the following configuration.
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--stable-2018.02-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_6=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_PYTHON3=y
It needs to be built in an environment that has libmpfr.so.4 installed
as the pre-built toolchain from that era did not include it. An easy
way to achieve this is to build this configuration under an old
Buildroot Docker container:
IMAGE=buildroot/base:20180205.0730 ./utils/docker-run make python3
With a build-time check, the autobuilders could get build failures when
generating such a config. However, the autobuilders cannot use a
toolchain with this configuration (they only use more recent
toolchains). Therefore, no update to genrandconfig is needed.
[1] https://gitlab.com/buildroot.org/buildroot/-/issues/95#note_2348479811
Cc: Vincent Fazio <vfazio@xes-inc.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Buildroot commit [1] "update to Bootlin toolchains 2025.08-1",
the TestMicroPython segfault when testing if micropython can return a
non-zero exit code.
micropython -c "import sys ; sys.exit(123)"
This issue is related to the gcc version used to build micropython
(gcc 14 or newer). Using gcc 13 (like Bootlin toolchain 2024.05-1
previously used) micropython run without issue.
The issue has been reported upstream [2] and fixed in newer micropython
releases [3]. For now, apply a temporary workaround (suggested in the
bug report) using -DMICROPY_NLR_SETJMP=1 only for gcc 14 or newer.
MICROPY_NLR_SETJMP avoid the architecture specific implementation of
nlr_push.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11176774762 (TestMicroPython)
[1] 947dbc92a2
[2] https://github.com/micropython/micropython/issues/14115
[3] 35f3f0a87d
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
TestRelroPartial is broken since the last checksec update to 2.7.1 [1]
(Buildroot 2024.08) due to a relro check fix [2] that doesn't work for
powerpc architecture where .got.plt doesn't exist for some reasons
(that's why the expected result "full" is replaced by "Partial").
From [3]:
if ${readelf} -d "${1}/exe" 2> /dev/null | grep -q 'BIND_NOW' || ! ${readelf} -l "${1}/exe" 2> /dev/null | grep -q '\.got\.plt'; then
echo_message '\033[32mFull RELRO \033[m ' 'Full RELRO,' ' relro="full"' '"relro":"full",'
else
echo_message '\033[33mPartial RELRO\033[m ' 'Partial RELRO,' ' relro="partial"' '"relro":"partial",'
checksec tool is problably tested upstream on more common architectures
like x86_64 or aarch64 than powerpc64 e5500. This may explain why
checksec broke on powerpc64 e5500 target.
Also, the Booltin powerpc64-e5500--glibc--stable-2018.02-2 toolchain
used by test_hardening tests was not updated since the hardening tests
were introduced back in 2018.11 release.
So, switch to the current Bootling aarch64 stable toolchain
(currently Bootlin aarch64 glibc stable 2025.08-1).
Checked that all 6 hardening tests pass with this new toolchain:
tests.core.test_hardening.TestFortifyConserv
tests.core.test_hardening.TestFortifyNone
tests.core.test_hardening.TestRelro
tests.core.test_hardening.TestRelroPartial
tests.core.test_hardening.TestSspNone
tests.core.test_hardening.TestSspStrong
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11176773995 (TestRelroPartial)
[1] 6150564974
[2] 1c80e39c49
[3] 1c80e39c49 (diff-9e8d1b28dfaf1c704560ac51a5613b70d70de2dcd84e87b9fa20f28811e6484aL1491)
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
iozone releases 3.507 and 3.508 seems to be only build fixes releases
for latest GCC compiler version but since there is no public vcs
it's not easy to review the history between releases and backport
any patches.
Based on the changelog from [1]:
Revision 3.507
Fix GCC compile warnings.
Revision 3.508
Put an end to the (&*% stupid GCC breaking builds for no valid reason.
So bump to the latest 508 release.
Rebase 0001-Add-new-targets-for-iozone.patch
Rebase 0002-fix-build-without-aio.patch and convert to git format
The TestIozone build issue is not yet fixed by the version bump [2].
[1] https://www.iozone.org/src/current/Changes.txt
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/11176774405
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 759a08633e ("package/mbpfan: fix build on musl / uclibc-ng") added a
patch for musl / uclibc-ng, but the upstream patch did not correctly apply
to the 2.4.0 release, breaking the build.
Fix that. In the mean time the patch has been applied upstream, so add a
reference to the upstream commit.
Fixes:
https://autobuild.buildroot.net/results/785be6231c1edc4e5461ce083a3d65fd27fc5843/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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
Also, since all Xilinx defconfigs have been bumped to Linux 6.12.40 with this
patch, the Linux 6.12.10 (2025.1) hash can be removed along with the
Linux 6.12.10 memory leak patch.
This patch has been run tested on the versal vek280 evaluation board.
This patch has been run tested on the versal vck190 evaluation board.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In the process of bumping Linux kernel 6.12.10 to 6.12.40, the size of the
default Linux kernel Image file for versal products is increasing from 23.4M
to 26.9M. This is leaving limited 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>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Bat pulls in the onig crate (version 6.4.0) through syntect with the
default "regex-onig" feature. This crate depends on the Oniguruma C
library (via onig_sys), which fails to build with GCC 15 due to C23
keyword conflicts. Newer versions of onig fix this issue, but bat
cannot directly update the onig version because it is pinned by syntect.
To resolve the build failure, apply a patch that replaces the
"regex-onig" feature with "regex-fancy" in bat's minimal-application
feature set. This switches bat to use the pure-Rust fancy-regex engine
instead of Oniguruma, avoiding the problematic onig_sys dependency.
Fixes:
https://autobuild.buildroot.net/results/ecc/ecc3b0c83e691e9a8ed5c7ff9d0a92ee06409f20
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
openal 1.22.0 does not build with GCC 15.x, but the backport of the
fixes to 1.22.0 turns out to be too complicated, so let's bump to
1.24.3 instead.
Since 1.24.3 uses C++17, and after testing with GCC 7.x, then GCC 8.x
then GCC 9.x, we found out that GCC 9.x at least is
necessary. Therefore, reverse dependencies are updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On the autobuilder the mariadb package fails to build when the
BR2_PACKAGE_LIBOPENSSL_ENABLE_RMD160 variable is not set.
See the following autobuilder error:
```
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c: In function 'ma_hash_get_algorithm':
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c:40:12: error: implicit declaration of function 'EVP_ripemd160'; did you mean 'LN_ripemd160'? [-Wimplicit-function-declaration]
40 | return EVP_ripemd160();
| ^~~~~~~~~~~~~
| LN_ripemd160
/workdir/instance-0/output-1/build/mariadb-10.11.11/libmariadb/libmariadb/secure/openssl_crypt.c:40:12: error: returning 'int' from a function with return type 'const EVP_MD *' {aka 'const struct evp_md_st *'} makes pointer from integer without a cast [-Wint-conversion]
40 | return EVP_ripemd160();
| ^~~~~~~~~~~~~~~
```
This error can be reproduced with the following config:
```
cat <<EOF >.config
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LIBOPENSSL=y
# BR2_PACKAGE_LIBOPENSSL_ENABLE_RMD160 is not set
BR2_PACKAGE_MARIADB=y
EOF
make olddefconfig
make mariadb
```
This patch adds a requirement to the RMD160 crypto for the MariaDB
package.
Fixes: https://autobuild.buildroot.org/results/f2b/f2b749cb7019856c5434c27987e8bfb2dc179cda
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
