igh-ethercat is failing while attempting to apply patches,
with error:
Applying 0002-Linux-6.19.0-support.patch using patch:
patching file devices/generic.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file devices/generic.c.rej
The package patch 0002 was added in [1] in branch "master" while it
was in release client cycle. It was cherry-picked in [2] in branch
"next" to apply the bump [3] (which removes the package patches 0001
and 0002). When the branch "next" was merged in "master" in commit [4],
the patch 0002 was kept.
This commit removes this stale patch.
[1] e4cf512c39
[2] 8a5fc970b4
[3] 0a91e760f4
[4] 5f26877955
Fixes:
- https://autobuild.buildroot.org/results/4f509f1f788c1b8dc5a840ffa2e435c5ed7b6eea/
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d071817969)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://github.com/strukturag/libde265/releases/tag/v1.1.2
Security fixes:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-xp3h-6f5r-8cxp) Heap use-after-free and double free
in multi-threaded (WPP) decoding. A crafted stream whose slice segments
repeat or rewind their slice_segment_address within a picture re-ran
CTB rows that were already marked finished, so the CABAC context handoff
between rows was no longer ordered and the shared context table was
released twice. Slice segments that do not follow the previous one in
tile-scan order are now rejected with the new warning
DE265_WARNING_SLICE_SEGMENT_ADDRESS_NOT_INCREASING, and the WPP row
progress is reset for each slice segment. (medium)
CVE-2026-XXXXX (GHSA-mm7m-v26f-wf8x) Heap use-after-free after
de265_reset(): the pointer to the previous slice header was left
dangling when the DPB was cleared, and a dependent slice pushed after
the reset copied from freed memory. (medium)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e55cb31085)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://github.com/strukturag/libheif/releases/tag/v1.23.3
Fixes the following CVEs:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-x8r2-mggj-j6wr) Heap buffer overflow (write) in the
uncompressed (unci) mixed-interleave decoder when the two chroma
components declare different bit depths. Both the written bytes and the
overflow length are controlled by the file. (critical)
CVE-2026-XXXXX (GHSA-8fmq-r4pf-7m57) Permanent decoder deadlock through
a reference cycle between an image and its alpha auxiliary image. The
alpha edge was not covered by the cycle guard and re-entered a held
mutex. (high)
CVE-2026-XXXXX (GHSA-w7mc-p8jc-p853) Heap out-of-bounds read in the
YCbCr 4:2:0 to 16-bit interleaved RGB conversion when the chroma
planes have a lower bit depth than luma. Heap memory could end up in
the decoded image. YCbCr conversions with mismatched luma and chroma
bit depths are now rejected. (high)
CVE-2026-XXXXX (GHSA-4jqm-2x34-6f6r) Heap buffer overflow in the SVT-AV1
encoder plugin when encoding a high-bit-depth alpha channel, and a
double free on its send-picture error path. (high)
CVE-2026-84451 (GHSA-hh47-fhqr-cj2r) Incomplete fix for
GHSA-73p7-m7gg-w2jv: the tile range check of the unci decoder (without
icef) could still overflow, allowing an out-of-bounds read. (medium)
CVE-2026-XXXXX (GHSA-4h82-g446-83fm) Heap out-of-bounds read when
converting odd-height 4:2:0 frames of an uncompressed (uncv) image
sequence to RGB. (medium)
CVE-2026-XXXXX (GHSA-9rj8-5mp5-26c9) Out-of-bounds read in the RGB to
YCbCr identity-matrix color conversion when the R, G, and B planes
have different bit depths. (medium)
CVE-2026-84450 (GHSA-gh5q-69gg-c964) A clap property combined with an
oversized ispe reached an assert() in the Fraction arithmetic and
aborted the process (incomplete fix for GHSA-jc8f-p23p-5hjg). An error
is returned instead. (medium)
(GHSA-mw6f-29j3-76f4) Several smaller findings:
heif_image_handle_get_depth_image_handle() and
heif_image_handle_get_depth_image_representation_info() dereferenced a
null pointer on files without a depth image; the TIFF input decoder of
the example tools had an unbounded EXIF tag allocation and a division
by zero on zero YCbCr subsampling; assert()s in the PNG input decoder
are now error returns; integer overflow in the Go binding's
ImageAccess.GetPlane(); heif-view now verifies the decoded frame size
before display. (medium)
(GHSA-8857-r8x5-7499) Undefined behavior (negative shift) in the HDR
bit-depth up-conversion for target bit depths above 16. Such
conversions are now rejected. (low)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d148168e20)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot 262a7f6d2f added the package but
forgot to provide the hash for LICENSE.GPL3-EXCEPT, instead a hash for
a non-existing file was added to qt5knx.hash.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d2b7199dea)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Regenerate the Bootlin toolchain Kconfig and test configurations using
support/scripts/gen-bootlin-toolchains.
This adds BR2_USE_MMU to the affected uClibc entries and to the
architecture support conditions, and updates the generated tests.
The glibc and musl changes only reorder their existing BR2_USE_MMU
dependencies.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9c6eed9ec0)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The Bootlin uClibc toolchains for m68k-68xxx, riscv32-ilp32d, and
xtensa-lx60 require an MMU. However, their generated Kconfig entries
lack a BR2_USE_MMU dependency, allowing them to be selected for noMMU
configurations. External toolchain validation then fails with:
MMU support available in C library, please enable BR2_USE_MMU
Add the missing BR2_USE_MMU dependencies for these architectures to
prevent them from being selected for noMMU targets.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 3469c6793c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Regenerate the Bootlin toolchain Kconfig file with
support/scripts/gen-bootlin-toolchains to remove duplicate
BR2_TOOLCHAIN_HAS_THREADS selections.
Commit 184d47a7ad ("support/scripts/gen-bootlin-toolchains: add new
script to support Bootlin toolchains") initially introduced this issue.
Although commit a33e1af4a0 ("support/scripts/gen-bootlin-toolchains:
avoid selecting _HAS_THREADS multiple times") fixed the generator script,
the Config.in.options file was not regenerated accordingly.
This is a non-functional cleanup, as repeated Kconfig select statements
are harmless.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9556895e78)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
DEJAVU_LICENSE is primarily BitstreamVera. The license file also
specifies that DejaVu-specific changes and certain math extensions are
in the Public Domain. This matches the licensing logic used by
OpenEmbedded/Yocto.
Signed-off-by: Martin Bachmann <martin.bachmann@designwerk.com>
[Fiona: wrap lines in commit message]
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
(cherry picked from commit df61b7e9bb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
See the changelogs:
- https://www.erlang.org/patches/OTP-26.2.5.16
- https://www.erlang.org/patches/OTP-26.2.5.17
- https://www.erlang.org/patches/OTP-26.2.5.18
- https://www.erlang.org/patches/OTP-26.2.5.19
- https://www.erlang.org/patches/OTP-26.2.5.20
- https://www.erlang.org/patches/OTP-26.2.5.21
This fixes the following vulnerabilities:
- CVE-2026-21620:
Relative Path Traversal, Improper Isolation or Compartmentalization
vulnerability in erlang otp erlang/otp (tftp_file modules), erlang otp
inets (tftp_file modules), erlang otp tftp (tftp_file modules) allows
Relative Path Traversal. This vulnerability is associated with program
files lib/tftp/src/tftp_file.erl, src/tftp_file.erl.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-21620
- CVE-2026-23941:
Inconsistent Interpretation of HTTP Requests ('HTTP Request
Smuggling') vulnerability in Erlang OTP (inets httpd module) allows
HTTP Request Smuggling. This vulnerability is associated with program
files lib/inets/src/http_server/httpd_request.erl and program routines
httpd_request:parse_headers/7. The server does not reject or
normalize duplicate Content-Length headers. The earliest Content-
Length in the request is used for body parsing while common reverse
proxies (nginx, Apache httpd, Envoy) honor the last Content-Length
value. This violates RFC 9112 Section 6.3 and allows front-end/back-
end desynchronization, leaving attacker-controlled bytes queued as the
start of the next request.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23941
- CVE-2026-23942:
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal') vulnerability in Erlang OTP (ssh_sftpd module) allows Path
Traversal. This vulnerability is associated with program files
lib/ssh/src/ssh_sftpd.erl and program routines
ssh_sftpd:is_within_root/2. The SFTP server uses string prefix
matching via lists:prefix/2 rather than proper path component
validation when checking if a path is within the configured root
directory. This allows authenticated users to access sibling
directories that share a common name prefix with the configured root
directory. For example, if root is set to /home/user1, paths like
/home/user10 or /home/user1_backup would incorrectly be considered
within the root.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23942
- CVE-2026-23943:
Improper Handling of Highly Compressed Data (Compression Bomb)
vulnerability in Erlang OTP ssh (ssh_transport modules) allows Denial
of Service via Resource Depletion. The SSH transport layer advertises
legacy zlib compression by default and inflates attacker-controlled
payloads pre-authentication without any size limit, enabling reliable
memory exhaustion DoS. Two compression algorithms are affected: *
zlib: Activates immediately after key exchange, enabling
unauthenticated attacks * zlib@openssh.com: Activates post-
authentication, enabling authenticated attacks Each SSH packet can
decompress ~255 MB from 256 KB of wire data (1029:1 amplification
ratio). Multiple packets can rapidly exhaust available memory, causing
OOM kills in memory-constrained environments. This vulnerability is
associated with program files lib/ssh/src/ssh_transport.erl and
program routines ssh_transport:decompress/2,
ssh_transport:handle_packet_part/4.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23943
- CVE-2026-28810:
Generation of Predictable Numbers or Identifiers vulnerability in
Erlang/OTP kernel (inet_res, inet_db modules) allows DNS Cache
Poisoning. The built-in DNS resolver (inet_res) uses a sequential,
process-global 16-bit transaction ID for UDP queries and does not
implement source port randomization. Response validation relies almost
entirely on this ID, making DNS cache poisoning practical for an
attacker who can observe one query or predict the next ID. This
conflicts with RFC 5452 recommendations for mitigating forged DNS
answers. inet_res is intended for use in trusted network environments
and with trusted recursive resolvers. Earlier documentation did not
clearly state this deployment assumption, which could lead users to
deploy the resolver in environments where spoofed DNS responses are
possible. This vulnerability is associated with program files
lib/kernel/src/inet_db.erl and lib/kernel/src/inet_res.erl.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-28810
- CVE-2026-32147:
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal') vulnerability in Erlang OTP ssh (ssh_sftpd module) allows
an authenticated SFTP user to modify file attributes outside the
configured chroot directory. The SFTP daemon (ssh_sftpd) stores the
raw, user-supplied path in file handles instead of the chroot-resolved
path. When SSH_FXP_FSETSTAT is issued on such a handle, file
attributes (permissions, ownership, timestamps) are modified on the
real filesystem path, bypassing the root directory boundary entirely.
Any authenticated SFTP user on a server configured with the root
option can modify file attributes of files outside the intended chroot
boundary. The prerequisite is that a target file must exist on the
real filesystem at the same relative path. Note that this
vulnerability only allows modification of file attributes; file
contents cannot be read or altered through this attack vector. If the
SSH daemon runs as root, this enables direct privilege escalation: an
attacker can set the setuid bit on any binary, change ownership of
sensitive files, or make system configuration world-writable. This
vulnerability is associated with program files
lib/ssh/src/ssh_sftpd.erl and program routines ssh_sftpd:do_open/4 and
ssh_sftpd:handle_op/4.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-32147
- CVE-2026-42789:
Improper Following of a Certificate's Chain of Trust vulnerability in
Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate
to be accepted as an intermediate issuer, enabling certificate chain
forgery. In lib/public_key/src/pubkey_cert.erl,
pubkey_cert:validate_extensions/7 contains two flaws that together
allow a certificate with basicConstraints cA:false and no keyUsage
extension to be used as an intermediate issuer in a chain passed to
public_key:pkix_path_validation/3: the cA:false clause recurses into
the remaining extensions without rejecting the certificate when it is
in issuer position, and the keyUsage check only fires when the
extension is present, so a certificate lacking keyUsage entirely
bypasses the keyCertSign enforcement. Any party holding an end-entity
certificate with basicConstraints cA:false and no keyUsage extension,
issued by any CA in the victim's trust store, can use that
certificate's private key to sign forged leaf certificates for
arbitrary identities. public_key:pkix_path_validation/3 accepts the
resulting chain, and by extension every TLS or mTLS endpoint built on
the OTP ssl application that relies on the default verifier is
affected, including server identity verification on the client side
and client certificate verification on mTLS servers.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-42789
- CVE-2026-42790:
Improper Certificate Validation vulnerability in Erlang OTP public_key
(pubkey_cert and public_key modules) allows a DNS nameConstraints
bypass via subject CommonName fallback in TLS hostname verification.
Two flaws combine to allow a subordinate CA whose DNS nameConstraints
are restricted (e.g. permitted;DNS:allowed.example.com) to issue a
leaf certificate that an OTP TLS client accepts as a valid identity
for an out-of-scope hostname (e.g. victim.example.com): First,
pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl
only checks SAN DNS entries against nameConstraints. Per RFC 5280, a
permitted DNS subtree only restricts certificates that contain a DNS-
typed name. A leaf with no subjectAltName therefore trivially
satisfies any permitted;DNS:... constraint regardless of its subject
commonName. Second, public_key:pkix_verify_hostname/3 in
lib/public_key/src/public_key.erl falls back to the subject commonName
when no subjectAltName is present, extracting id-at-commonName
attributes as presented IDs and matching them against the reference
hostname. The strict pkix_verify_hostname_match_fun(https) matcher
does not suppress this fallback. The result is that path validation
accepts a CN-only leaf under a DNS-constrained intermediate (no SAN
means the nameConstraints are not triggered), and hostname
verification then accepts it via the CN fallback. The bypass is
reachable from stock ssl:connect with verify_peer, a trusted CA, SNI,
and the canonical strict https hostname matcher.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-42790
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit dfc909b1cd)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
This patch fixes a build error with OpenSSL-enabled libcurl which was
detected by the Gitlab pipelines:
checking for openssl options with pkg-config... found
configure: pkg-config: SSL_LIBS: "-lssl -lcrypto -pthread"
configure: pkg-config: SSL_LDFLAGS: "-L/builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib"
configure: pkg-config: SSL_CPPFLAGS: ""
checking for HMAC_Update in -lcrypto... no
checking for HMAC_Init_ex in -lcrypto... no
checking OpenSSL linking with -ldl... no
checking OpenSSL linking with -ldl and -lpthread... no
checking for SSL_set_quic_use_legacy_codepoint... no
checking for SSL_set_quic_tls_cbs... no
configure: OpenSSL version does not speak any known QUIC API
configure: OPT_OPENSSL: /builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/host/m68k-buildroot-uclinux-uclibc/sysroot/usr
configure: OPENSSL_ENABLED:
configure: error: --with-openssl was given but OpenSSL could not be detected
make[1]: *** [package/pkg-generic.mk:263: /builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-5208-uclibc/build/libcurl-8.21.0/.stamp_configured] Error 1
Although OpenSSL was found using pkg-config the build tests fail.
A local build shows the concrete error in config.log, for example:
configure:27577: checking for HMAC_Update in -lcrypto
configure:27599: /home/bernd/buildroot/output/host/bin/m68k-linux-gcc
-o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g0 -fno-dwarf2-cfi-asm -Wl,-elf2flt=-r
-static -Werror-implicit-function-declaration -Wno-system-headers
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE -Wl,-elf2flt=-r -static
-L/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib
-L/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib
conftest.c -lcrypto -lssl -lcrypto -lz -pthread -lz >&5
/home/bernd/buildroot/output/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/ld.real:
/home/bernd/buildroot/output/host/bin/../m68k-buildroot-uclinux-uclibc/sysroot/usr/lib/libcrypto.a(libcrypto-lib-threads_pthread.o):
in function `ossl_rcu_read_lock':
threads_pthread.c:(.text+0xa4): undefined reference to `__atomic_fetch_add_8'
This error occurs many times for various atomic operations:
$ grep "undefined reference to \`__atomic" output/build/libcurl-8.20.0/config.log | sort -u | grep -v real
threads_pthread.c:(.text+0x28a): undefined reference to `__atomic_fetch_sub_8'
threads_pthread.c:(.text+0x3b4): undefined reference to `__atomic_fetch_add_8'
threads_pthread.c:(.text+0x9c8): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xa4): undefined reference to `__atomic_fetch_add_8'
threads_pthread.c:(.text+0xa9c): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xb66): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xc30): undefined reference to `__atomic_is_lock_free'
threads_pthread.c:(.text+0xcdc): undefined reference to `__atomic_is_lock_free'
The build error can be reproduced with the current buildroot tree using
this defconfig:
BR2_m68k=y
BR2_m68k_cf5208=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_M68K_COLDFIRE_UCLIBC_STABLE=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
Although the toolchain lacks atomics support
$ grep ATOMIC .config
$
it emits atomic-related defines, for example:
$ echo | output/host/bin/m68k-linux-gcc -dM -E - | grep __ATOMIC_ACQ_REL
#define __ATOMIC_ACQ_REL 4
$
This specific define __ATOMIC_ACQ_REL is used in OpenSSL to enable
atomic support at various places:
https://github.com/openssl/openssl/blob/openssl-3.6.3/crypto/threads_pthread.c
causing the build errors we see with the mentioned defconfig.
To fix the problem we use an OpenSSL-provided define to forcefully
disable the usage of atomic intrinsics.
The misdetection of atomic intrinsics for m68k coldfire is not a new
problem:
https://lists.buildroot.org/pipermail/buildroot/2017-May/180841.htmlhttps://lists.buildroot.org/pipermail/buildroot/2026-May/803110.html
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5f8d0b78ec)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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 turns out that mdnsd is started by S50mdnsd before the
emulator.login() change the system date:
[BRTEST# date -s @1788032864
Sat Aug 29 19:47:44 UTC 2026
Since the minimal rootfs.cpio generated for TestMdnsd doesn't have any
ntp client installed, it start with "January 1, 1970".
The date change may cause some issue to the mdnsd daemon which blocks
any response from mquery command.
When the problem occurs, "mquery -T _http._tcp" reply is empty:
# mquery -T _http._tcp
Querying _http._tcp.local. for PTR (12) ... press Ctrl-C to stop
To workaround the issue, restart mdnsd manually.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948555
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 45636d67c9)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Dracut-internal executables were linked against system libraries,
instead of Buildroot host packages. For example:
$ ldd host/lib/dracut/dracut-install
linux-vdso.so.1 (0x00007f578cf06000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f578cccd000)
libkmod.so.2 => /usr/lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f578ccb1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f578cf08000)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f578c600000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f578cc92000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f578c536000)
The reason is that Dracut is not a "real" autoconf package, and the
hand-written ./configure script does not preserve LDFLAGS for
make. Pass the environment variables directly to fix this.
Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
[Julien: add comment in dracut.mk]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 45acb281ca)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
examples/vm_power_manager/meson.build in DPDK detects the presence of
libvirt:
opt_dep = cc.find_library('virt', required : false)
and then builds some examples or not depending on the availability of
libvirt. Let's make this optional dependency explicit in dpdk.mk, even
if there's no explicit enable/disable option for it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 55a7ece9e5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When libvirt is present before DPDK is built, some additional examples
are compiled. One of them fails to build due to a missing <stdlib.h>
include. Let's import a patch from OpenSuse, that we have submitted
upstream, to fix this issue.
We couldn't find any autobuilder failure for this issue, but the
following defconfig allows to reproduce the failure:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_DPDK=y
BR2_PACKAGE_DPDK_EXAMPLES=y
BR2_PACKAGE_LIBVIRT=y
The problem exists since DPDK v19.11, so it has been in Buildroot
since DPDK was introduced in commit
d17d1b6bde.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit db3d0d44ac)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot commit [1] (package/perl: fix build issue with musl)
introduced a patch that is meant to be applied on top of perl-cross,
which is extracted on top of perl only in the target variant.
Since the patch was introduced as a normal package patch, the Buildroot
infra is trying to always apply it, even for the host package variant.
Since perl-cross is not extracted for the host variant, some patched
files are missing. In that case, the host-perl is failing with error:
>>> host-perl 5.42.3 Patching
Applying 0001-configure-keep-_GNU_SOURCE-in-build-flags.patch using patch:
can't find file to patch at input line 46
This commit fixes the issue by moving the package patch in a dedicated
"perl-cross" subdirectory, to make sure it will no longer be applied by
the infra. We apply the patch only for the target package variant using
a _POST_PATCH_HOOKS hook.
Fixes:
- [1]
- https://gitlab.com/buildroot.org/buildroot/-/jobs/16185948610 (TestPerlXMLLibXML)
- ...and few other tests requiring host-perl
[1] d950fff290
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8dea6e7c08)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When OpenSSL is enabled, if DES support is enabled, OpenSSH uses
DES_crypt. However, without OpenSSL or its DES support, there is no
available crypt() implementation for OpenSSH libopenbsd-compat xcrypt()
function, resulting in the following error:
.../host/bin/i686-buildroot-linux-gnu-gcc -o sshd-auth sshd-auth.o
auth2-methods.o auth-rhosts.o auth-passwd.o sshpty.o sshlogin.o
servconf.o serverloop.o auth.o auth2.o auth-options.o session.o
auth2-chall.o groupaccess.o auth-bsdauth.o auth2-hostbased.o
auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o
auth2-pubkeyfile.o auth2-gss.o gss-serv.o gss-serv-krb5.o
monitor_wrap.o auth-krb5.o audit.o audit-bsm.o audit-linux.o
platform.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o
sandbox-null.o sandbox-rlimit.o sandbox-darwin.o
sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-solaris.o
sftp-server.o sftp-common.o uidswap.o ssh-pkcs11-client.o
ssh-sk-client.o -L. -Lopenbsd-compat/ -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0
-D_FORTIFY_SOURCE=1 -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-fstack-protector-strong -pie -lssh -lopenbsd-compat
-L.../host/bin/../i686-buildroot-linux-gnu/sysroot/usr/lib
-lssl -lcrypto -lcrypto -lz
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt'
.../host/lib/gcc/i686-buildroot-linux-gnu/15.3.0/../../../../
i686-buildroot-linux-gnu/bin/ld:
openbsd-compat//libopenbsd-compat.a(xcrypt.o): in function `xcrypt':
xcrypt.c:(.text+0x51): undefined reference to `crypt' collect2: error:
ld returned 1 exit status make[2]: *** [Makefile:233: sshd-auth] Error
1 make[2]: *** Waiting for unfinished jobs.... collect2: error: ld
returned 1 exit status make[2]: *** [Makefile:230: sshd-session] Error
1 make[1]: *** [package/pkg-generic.mk:273:
.../build/openssh-10.4p1/.stamp_built]
Error 2 make: *** [Makefile:83: _all] Error 2
This commit enables BR2_PACKAGE_LIBXCRYPT with OpenSSH as long as
glibc is used. Since "sshd-auth" is compiled regardless of
BR2_PACKAGE_OPENSSH_SERVER, we need to enable it with BR2_PACKAGE_OPENSSH.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.wesolowski@mobileye.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 913512e302)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the website accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2eefcb245f)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
patchwork.buildroot.org used to be a redirect to patchwork.ozlabs.org,
but we are now running our own instance, so let's adjust the links in
the manual accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2d7d9d8200)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
This fixes the following known vulnerabilities:
- CVE-2026-19499
- CVE-2026-77117
- CVE-2026-80489
(alternative to commit be382f6061)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When BR2_PACKAGE_OPENCV4_WITH_WEBP=y we need to enable mux and demux
support in webp, otherwise the build of OpenCV fails as follows:
CMake Error: The following variables are used in this project,
but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly
in the CMake files:
WEBP_DEMUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
WEBP_MUX_LIBRARY
linked by target "opencv_imgcodecs"
in directory [...]/build/opencv4-4.13.0/modules/imgcodecs
The issue already exists in 2025.02.x.
Fixes:
https://autobuild.buildroot.net/results/d3e0446a87d32469267e241866c4224143170f31/
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e1ec936cf7)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Even though it's only documentation, the form of the names of the
post-image.sh and post-build.sh scripts should be consistent with the
names of those scripts used in the code base, using hyphen, not
underscore.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c529a2c286)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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>
(cherry picked from commit 5ea2135a56)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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>
(cherry picked from commit 0fe2d74ffd)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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>
(cherry picked from commit 83fc4aa55e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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>
(cherry picked from commit e06cfae9cb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
