Commit 1f7efaf89f ("package/qemu: do not support x86_steamroller or
x86_core_avx2") excluded BR2_x86_core_avx2 from
BR2_PACKAGE_HOST_QEMU_ARCH_SUPPORTS because binaries built for that CPU
variant crashed under qemu-user. This was done at the time of Qemu 4.2,
whose TCG engine did not implement AVX at all.
Since Qemu 7.2, the TCG engine implements AVX, AVX2, F16C, FMA3 and
VAES. In Qemu 11.0.0 (the version we currently package) and 11.1.1,
target/i386/cpu.c has:
#define TCG_EXT_FEATURES (... | CPUID_EXT_AVX | CPUID_EXT_F16C | \
CPUID_EXT_FMA | ...)
#define TCG_7_0_EBX_FEATURES (... | CPUID_7_0_EBX_BMI1 | \
CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_AVX2 | ...)
which covers everything gcc generates for -march=core-avx2.
In addition, the exclusion was inconsistent: gcc's core-avx2 is a
deprecated alias for haswell, both variants select exactly the same
BR2_X86_CPU_HAS_* symbols in arch/Config.in.x86, and haswell was never
excluded. The same goes for broadwell, skylake, zen*, x86-64-v3, ...,
which all enable AVX2 and build fine on the autobuilders.
So drop the BR2_x86_core_avx2 exclusion.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 8d80efe017)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Fixes:
https://autobuild.buildroot.net/results/d43/d4364f6e3636c696471bf8cba6d308439130e53a/
In function 'MakeIv',
inlined from 'TestSymmetricAlgorithm' at AlgorithmTests.c:197:25:
AlgorithmTests.c:181:23: error: writing 32 bytes into a region of size
16 [-Werror=stringop-overflow=]
The build error occurs with gcc 15.x on some platforms, gcc 14.x is not
affected.
These defconfigs build without this patch:
BR2_x86_64=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_PACKAGE_IBM_SW_TPM2=y
This gcc-15 based defconfig is broken:
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_PACKAGE_IBM_SW_TPM2=y
The build error is not related to the recent bump of the package from
rev183-2024-03-27 to rev183-2026-08-26 because no changes were committed
upstream to AlgorithmTests.c since rev183-2024-03-27:
https://github.com/kgoldman/ibmswtpm2/commits/master/src/AlgorithmTests.c
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b016989c61)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Fixes build error:
In file included from client.c:14:
client.c: In function 'JNI_OnLoad':
./../../src/est/est.h:834:10: error: implicit declaration of function 'ERR_load_crypto_strings'; did you mean 'ERR_load_CRYPTO_strings'? [-Wimplicit-function-declaration]
834 | do { ERR_load_crypto_strings(); \
| ^~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
./../../src/est/est.h:836:10: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
836 | ENGINE_load_builtin_engines(); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
client.c: In function 'JNI_OnUnload':
./../../src/est/est.h:860:40: error: implicit declaration of function 'ENGINE_cleanup'; did you mean 'EVP_PBE_cleanup'? [-Wimplicit-function-declaration]
860 | OBJ_cleanup(); EVP_cleanup(); ENGINE_cleanup(); \
| ^~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
./../../src/est/est.h:862:10: error: implicit declaration of function 'ERR_free_strings'; did you mean 'ERR_load_EC_strings'? [-Wimplicit-function-declaration]
862 | ERR_free_strings(); } while (0)
| ^~~~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
client.c: In function 'est_client_raise_exception':
client.c:122:17: error: implicit declaration of function 'ERR_print_errors_fp' [-Wimplicit-function-declaration]
122 | ERR_print_errors_fp(stderr);
| ^~~~~~~~~~~~~~~~~~~
seen with this defconfig
BR2_PACKAGE_OPENJDK=y
BR2_PACKAGE_LIBEST=y
The failing code was added upstream on Jul, 6th, 2020:
ab998c0918
and included in version 3.2.0.
Buildroot commit 5bbb1834a4 bumped the
package to a tree including the aforementioned upstream commit on Jul
24th, 2022 so a backport to LTS branches should be considered.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 7e34cd7c7e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://lists.exim.org/lurker/message/20260820.154633.91995f73.en.html
Rebased patch 0001.
Updated patch 0005, the previous version was applied upstream with
commit 497e9eb7e77ad27ae1d45281e23eefadfaa7a3bc but it did not fix all
linker errors so we sent a new patch upstream which replaces the
previous patch.
Updated hash of GPL-2.0 license file (address, name of president and
typos), a commit can not be provided from the source tree.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 8b009489f5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Add an infrastructure test case to verify that the per-package
<PKG>_FLAT_STACKSIZE variable correctly configures the stack size in the
generated FLAT binary header.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 0bf4525045)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The comment should be shown when !BR2_INSTALL_LIBSTDCPP is true, also
treat BR2_PACKAGE_LIBURCU_ARCH_SUPPORTS as arch dependency.
Fixes: 54f96add94 ("package/bind: security bump version to 9.20.24")
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 96ac57460f)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
No autobuilder errors were recorded, the build error can be reproduced
with this defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_QT5WEBENGINE=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 60dc97fcee)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Building gobject-introspection for an x86 CPU variant with AVX512 fails
when g-ir-scanner runs the freshly built target binaries under
qemu-user:
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
The Qemu TCG engine implements AVX, AVX2, F16C, FMA3 and VAES since Qemu
7.2, but it does not implement the AVX512 instruction set at all [0].
Therefore no -cpu value passed through
BR2_PACKAGE_HOST_QEMU_USER_MODE_ARGS can make such binaries run, and
user-mode emulation is simply not possible for these CPU variants.
Mark those CPUs as unsupported by host-qemu, the same way it is already
done for x86_steamroller and x86_core_avx2. This relies on the existing
BR2_X86_CPU_HAS_AVX512 symbol, so all AVX512 capable variants are
covered, and it disables gobject-introspection and nodejs, which are the
two packages needing host-qemu in user mode.
[0] https://gitlab.com/qemu-project/qemu/-/issues/2878
Fixes:
https://autobuild.buildroot.org/results/7ed7f9c36dae1ddb965a0f0021db6cd319927b47/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c2bd6148c6)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WPEWEBKIT option.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 251a80dd9d)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5279b2303c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The 0002-Update-linker-flags.patch assumes that the qemu-xen files are included
in the xen source tree. However, if BR2_PACKAGE_XEN_TOOLS is not enabled, the
qemu-xen dependency will not be handled and the patch will fail to apply with
the following error.
Fixes: build error below
Applying 0002-Update-linker-flags.patch using patch:
patching file tools/Makefile
Hunk #1 succeeded at 36 (offset -1 lines).
Hunk #2 succeeded at 185 (offset -8 lines).
can't find file to patch at input line 76
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tools/qemu-xen/include/hw/xen/xen_native.h b/tools/qemu-xen/include/hw/xen/xen_native.h
|index 6bcc83ba..2590904e 100644
|--- a/tools/qemu-xen/include/hw/xen/xen_native.h
|+++ b/tools/qemu-xen/include/hw/xen/xen_native.h
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
make: *** [package/pkg-generic.mk:239: output/build/xen-4.21.1/.stamp_patched] Error 1
To avoid making BR2_PACKAGE_XEN_TOOLS a required option, fix the
0002-Update-linker-flags.patch so that modifying source from the qemu-xen
package is no longer included.
Instead of patching qemu-xen, a better solution is undefining the
__XEN_INTERFACE_VERSION__ from the qemu-xen package.
To test:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_XEN=y
# BR2_PACKAGE_XEN_TOOLS is not set
Signed-off-by: Neal Frager <neal.frager@amd.com>
Tested-by: Matt Weber <matt@thewebers.ws>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f63e572432)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_GLSLSANDBOX_PLAYER_SCRIPTS needs the full blown version of
bash and coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but
it does so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense,
but is not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 22540e0d41)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_XEN_TOOLS needs the full blown version of bash and
coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but it does
so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense, but is
not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e62e06b19d)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
ndctl selects kmod and keyutils, both of which depend on
!BR2_STATIC_LIBS, but this dependency was not propagated into ndctl
when the package was introduced. This commit fixes this issue.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6dad789282)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The Config.in comment has the correct dependency on
!BR2_TOOLCHAIN_HAS_THREADS, but that was not reflected in the comment
text itself.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3472fd59af)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_STRONGSWAN_BOTAN selects BR2_PACKAGE_BOTAN, but since
commit 10a70b1af6, botan needs gcc 11,
which was not propagated to strongswan's botan option. This commit
fixes this issue.
Fixes: 10a70b1af6 ("package/botan: needs gcc >= 11")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b56072c126)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
gerbera selects BR2_PACKAGE_ICU, which depends on !BR2_BINFMT_FLAT,
but this dependency was not propagated to gerbera. In practice this is
not an issue because gerbera depends on BR2_USE_MMU, and only noMMU
platforms can use BR2_BINFMT_FLAT. But for the sake of completeness,
let's propagate this dependency.
Note: in the Config.in comment, we handle it like an architecture
dependency, like is done in package/icu/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6b716763e9)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Since the bump of libabseil-cpp in commit
76241e89e1, it requires gcc 10. As part
of this commit, the protobuf package was updated, but not its reverse
dependency netdata. This commit fixes this issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e91ffb1afb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_SYSPROF selects BR2_PACKAGE_LIBDEX but did not propagate:
depends on BR2_TOOLCHAIN_HAS_UCONTEXT || \
BR2_PACKAGE_LIBUCONTEXT_ARCH_SUPPORTS
from libdex. This commit fixes this missing dependency. In terms of
Config.in comment, we do the same as what libdex is doing: handle it
as a toolchain dependency (rather than an architecture dependency).
This was missed in commit a73ef093f7,
which added the ucontext related dependency to libdex, without
propagating it to sysprof.
Fixes: a73ef093f7 ("package/libdex: needs ucontext")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit cd5eab10fe)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER selects
BR2_PACKAGE_GRAPHICSMAGICK, but did not propagate its BR2_USE_MMU
dependency. This issue exists since the package was introduced in
commit e821078031.
It fixes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_GRAPHICSMAGICK
Depends on [n]: BR2_USE_MMU [=n] && BR2_TOOLCHAIN_HAS_THREADS [=y]
Selected by [y]:
- BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER [=y] && BR2_PACKAGE_RPI_RGB_LED_MATRIX [=y]
which occurs when you configure an ARM noMMU FDPIC toolchain (because
we have noMMU, but shared libraries, so rpi-rgb-led-matrix can be
enabled).
Fixes: e821078031 ("package/rpi-rgb-led-matrix: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e67b301f53)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
There's recently been autobuilder failures on
toolchain-external-bootlin, but I wasn't getting notified in the daily
autobuilder e-mail for those failures, which sounded odd as DEVELOPERS
contains:
N: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[...]
F: toolchain/
And indeed, testing:
$ ./utils/get-developers -p toolchain-external-bootlin
returned nothing.
Turns out that the regexp FIND_INFRA_IN_PATCH and FIND_INFRA_IN_MK
used to find the package infrastructure, and ultimately decide if a
given .mk file contains a package, was a bit too strict:
"^\+\$\(eval \$\((host-)?([^-]*)-package\)\)$"
This would only allow packages named <something>-package or
host-<something>-package, but the <something> should not contain any
dash ("-"). So this works fine for cmake-package,
host-autotools-package, but not for toolchain-external-package where
<something> is toolchain-external and it contains a dash.
We fix this by relaxing the regexp a bit and allowing any character in
<something>. Consider the rest of the regexp that expects $(eval
$(<host>-<something>-package)), it seems highly unlikely to match
anything else but the line we're interested in.
With this fix:
$ ./utils/get-developers -p toolchain-external-bootlin
Giulio Benetti <giulio.benetti@benettiengineering.com>
Romain Naour <romain.naour@gmail.com>
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This issue has existed since the toolchain-external-package
infrastructure had been added.
Fixes: 1c99d70e52 ("toolchain-external: introduce toolchain-external-package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 592d5c517e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Building zabbix without libcurl enabled would lead to the following
error:
/usr/bin/ld: .../src/libs/zbxxml/xml.c:515:(.text+0x1c64): undefined reference to `zbx_vector_str_append'
This issue has been addressed in the upstream commit [1] and backported
as a patch in Buildroot.
For more information see the upstream issue [2].
This error is reproducible with the following defconfig:
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_ZABBIX=y
BR2_PACKAGE_ZABBIX_SERVER=y
BR2_PACKAGE_ZABBIX_SERVER_COPY_FRONTEND=y
EOF
make oldefconfig
make zabbix
[1] https://git.zabbix.com/projects/ZBX/repos/zabbix/commits/e8333ca2128
[2] https://support.zabbix.com/browse/ZBX-27635
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 489aefc22a)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Zabbix 7.2 is EOL since December 2025 [1]
For more info on the version bump, see:
- https://www.zabbix.com/rn/rn7.2.14
- https://www.zabbix.com/rn/rn7.2.15
This fixes the following vulnerabilties:
- CVE-2026-23920:
Host and event action script input is validated with a regex (set by
the administrator), but the validation runs in multiline mode. If ^
and $ anchors are used in user input validation, an injected newline
lets authenticated users bypass the check and inject shell commands.
https://www.cve.org/CVERecord?id=CVE-2026-23920
- CVE-2026-23921:
A low privilege Zabbix user with API access can exploit a blind SQL
injection vulnerability in include/classes/api/CApiService.php to
execute arbitrary SQL selects via the sortfield parameter. Although
query results are not returned directly, an attacker can exfiltrate
arbitrary database data through time-based techniques, potentially
leading to session identifier disclosure and administrator account
compromise.
https://www.cve.org/CVERecord?id=CVE-2026-23921
[1] https://endoflife.date/zabbix
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 055a1e249c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
check-package reports six warnings on S60lldpd: indentation with
spaces, no DAEMON variable, and shellcheck complaints.
The script also masks failures, the exit status of
"[ $? = 0 ] && echo OK || echo FAIL" is the one of echo, so start and
stop always return success. Stopping does not wait for the daemon to
exit either, so a restart can race the instance on its way out.
Rewrite it after package/busybox/S01syslogd, as the manual asks. lldpd
daemonizes and writes the PID file itself, but does not remove it on
exit, so pass the PID file to both start-stop-daemon and the daemon and
drop the stale file once the process is gone. Also pick up arguments
from /etc/default/lldpd and add the customary reload alias.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
[Julien: remove .checkpackageignore entry to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2fd1f6b629)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
In commit 203725a46b ("package/clamav:
bump version to 1.0.1"), select BR2_PACKAGE_JSON_C was added to
BR2_PACKAGE_CLAMAV without propagating the BR2_TOOLCHAIN_HAS_SYNC_4
dependency from BR2_PACKAGE_JSON_C.
Since at the same time a dependency on
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS was added to clamav and
Rust is not supported on the few architectures that don't have 4-byte
sync intrinsics, this has basically no effect, but ensure a correct
propagation of dependencies.
Fixes: 203725a46b ("package/clamav: bump version to 1.0.1")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 39b840beef)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_FALCOSECURITY_LIBS selects BR2_PACKAGE_HOST_GRPC and
BR2_PACKAGE_HOST_PROTOBUF, neither of which exists. These selects are
anyway not needed, so drop them.
Fixes: a15e35c4eb ("falcosecurity-libs: add new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7f5bb493e2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_WEBKITGTK_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WEBKITGTK_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WEBKITGTK option.
Fixes: e6e549b9e4 ("ffmpeg: add BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit da90655637)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit ef92929504)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_LIBSSH_OPENSSL unconditionnally selects
BR2_PACKAGE_LIBOPENSSL_ENGINES even though libressl is also supported
as an OpenSSL provider (and BR2_PACKAGE_LIBOPENSSL_ENGINES doesn't
make sense for libressl).
This causes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBOPENSSL_ENGINES
Depends on [n]: <choice> && BR2_PACKAGE_LIBOPENSSL [=n]
Selected by [y]:
- BR2_PACKAGE_LIBSSH_OPENSSL [=y] && <choice> && BR2_PACKAGE_OPENSSL [=y]
We checked that libssh, with OpenSSL support and libressl selected as
an OpenSSL provider works fine, using 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_LIBSSH=y
BR2_PACKAGE_LIBSSH_SERVER=y
BR2_PACKAGE_LIBRESSL=y
Fixes: 62103be918 ("package/libssh: select BR2_PACKAGE_LIBOPENSSL_ENGINES")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f7fe354ada)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_QT5CINEX selects BR2_PACKAGE_QT5BASE_PNG,
BR2_PACKAGE_QT5BASE_WIDGETS and BR2_PACKAGE_QT5BASE_EGLFS, which are
all sub-options of BR2_PACKAGE_QT5BASE_GUI, but we don't explicitly
selects BR2_PACKAGE_QT5BASE_GUI.
It turns out that things work because the package selects
BR2_PACKAGE_QT5GRAPHICALEFFECTS, which selects
BR2_PACKAGE_QT5DECLARATIVE_QUICK, which selects
BR2_PACKAGE_QT5BASE_GUI, but that is rather non-obvious, and it makes
more sense for BR2_PACKAGE_QT5CINEX to directly select
BR2_PACKAGE_QT5BASE_GUI if it also selects sub-options of it.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f077ba9e67)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
- BR2_PACKAGE_IVI_HOMESCREEN_AUDIO_PLAYERS selects gstreamer1, which
has a depends on BR2_USE_MMU, but does not propagate it
- BR2_PACKAGE_IVI_HOMESCREEN_FLUTTER_SECURE_STORAGE_PLUGIN selects
libsecret, which has a depends on BR2_USE_MMU, but does not propagate
it
In practice there is no problem since ivi-homescreen depends on glibc,
and glibc doesn't support any noMMU architecture. But just by walking
the chain of option dependencies, this is not something that is
theoretically guaranteed (making automated verification of
dependencies difficult).
The other "depends on" from gstreamer1 and libsecret, BR2_USE_WCHAR
and BR2_TOOLCHAIN_HAS_THREADS are on the other hand already handled by
the top-level BR2_PACKAGE_IVI_HOMESCREEN option, so there is no
ambiguity.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 90aeea08bb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_PULSEVIEW selects BR2_PACKAGE_QT5BASE_PNG and
BR2_PACKAGE_QT5BASE_WIDGETS, which both depend on
BR2_PACKAGE_QT5BASE_GUI. It ends working because we also select
BR2_PACKAGE_QT5SVG, which selects BR2_PACKAGE_QT5BASE_GUI, so there is
no bug, but it's bit inconsistent to select sub-options that have a
"depends on" without selecting the option they depend on.
This not a bug fix, it has no functional implication.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit aff091c39d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
pocketpy enables thread support by default (PK_ENABLE_THREADS=ON) and
then requires Threads from cmake, which fails on toolchains without
thread support:
CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Threads (missing: Threads_FOUND)
Thread support is optional, so enable it only when the toolchain
provides threads.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 376daf3dd0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The definition of BR2_PACKAGE_KODI_ARCH_SUPPORTS is incorrect, it
goes like this:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
default y if BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
so it means it would be "y" if either
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS *OR*
BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS is true. While clearly what
we need is for both to be true: ffmpeg should be available for the
target architecture, and openjdk should be available for the host
architecture.
One option was to change to:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS && BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Or:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
But we preferred:
bool
default y
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Fixes: b6a2f49429 ("package/kodi: depend on host-openjdk-bin instead of selecting BR2_NEEDS_HOST_JAVA")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 00e83bc24d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
