Now that binutils 2.47 has been introduced and binutils 2.46.1 made
the default version, drop the oldest supported version, binutils 2.44,
keeping only the 3 last versions supported: 2.45.1, 2.46.1 and 2.47.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that support for binutils 2.47 has been introduced, we follow our
policy of making binutils 2.46.1 the default version.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 7.1.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
Buildroot commit 9a43bf6593 bumped the gcc
dependency from 9 to 10 but forgot to propagate this change to the
libcamera-apps package.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Largely a bugfix release. Fixes an encryption issue if the cleartext was
exactly 8KB + N*64KB long.
https://git.sr.ht/~min/agec/refs/1.0.0
Drop now upstreamed 0001-io.c-isarmor-do-not-set-eof-for-35-byte-files.patch:
7a529662f9
Upstream renamed the agec-keygen utility to agecgen, so update the test to
match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Release announce:
https://lore.freedesktop.org/wayland-devel/alXq76OX4dVWoP3M@xpredator/T/#u
Removed already-deprecated config options:
* 'deprecated-backend-drm-screencast-vaapi' [1].
* 'deprecated-shell-fullscreen' [2].
* 'deprecated-screenshare' [3].
The 'pipewire' and 'remoting' plugins has been deprecated in [4].
They have already been removed in the main development branch in
upstream commit [5] and [6] (not yet in this version 16.0.0).
This commit removes the "remoting" option (rather than changing it to
"deprecated-remoting") because Buildroot was not enabling this option
and this deprecated option is now disabled by default.
This commit also removes the "pipewire" option (rather than changing
it to "deprecated-pipewire"). The commit log of [4] says the
replacement is the "pipewire-backend" option, which is already used
in Buildroot.
Tested on STM32MP157C-DK2.
[1] 7c3e3d7544
[2] 29b740ffee
[3] 3bd77f7817
[4] ec74bd0403
[5] 4606c49d28
[6] d587dfea5b
Signed-off-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
[Julien:
- update link in hash file comment
- add removed options in Config.in.legacy
- add back package patch which is not included in release
- reword commit log (fix and add links to upstream commits)
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
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>
Release notes:
https://lists.gnupg.org/pipermail/gnupg-announce/2026q3/000508.html
Contains a number of bugfixes, some of which may have (low severity)
security impact. As stated by Werner Koch:
All in all we received 26 reports alone from ANSSI but as even the reporter
mentioned, the real world attack severity is not critical. Thus we don't
consider 1.12.3 a security fix release. There are some bugs which should
be fixed to avoid crashes, and thus may lead to DoS. However, 16384 bit
RSA keys can also be used for a practical DoS; it all depends on your use
case.
https://www.openwall.com/lists/oss-security/2026/08/31/11
Added upstream patch to fix a build error introduced by this bump that
was detected by the Gitlab pipelines:
sm4-intel-avx512-amd64.S: Assembler messages:
sm4-intel-avx512-amd64.S:138: Error: operand size mismatch for `vsm4rnds4'
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: add extra info in commit log from Peter original submission from
https://lore.kernel.org/buildroot/20260901192724.1021544-1-peter@korsgaard.com/
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a basic runtime test for nano. The test attempts to write a file
using the editor.
Signed-off-by: Franciszek Stachura <fbstachura@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
dtui depends on tui-textarea which unconditionally imports AtomicU64 in
src/widget.rs to pack a viewport rectangle into a single atomic word:
use std::sync::atomic::{AtomicU64, Ordering};
pub struct Viewport(AtomicU64);
As there is no cfg(target_has_atomic) guard in tui-textarea, its
build fails on any target for which rustc does not provide 64-bit
atomics with:
Compiling tui-textarea v0.7.0
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
--> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
|
10 | use std::sync::atomic::{AtomicU64, Ordering};
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
|
help: a similar name exists in the module
|
10 - use std::sync::atomic::{AtomicU64, Ordering};
10 + use std::sync::atomic::{AtomicU32, Ordering};
This has been reported to tui-textarea upstream, but unfortunately the
project seems to be unmaintained (issue linked below). A sane workaround
is to disable the package on targets which lack 64-bit atomic support,
which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_U64
describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
which lack 64-bit atomics, and y everywhere else.
The same problem was hit by package/dust and worked around in commit
3abc3b97ba ("package/dust: bump to version 1.1.2") by bumping to a
version in which upstream had added the missing guard. That is not an
option here as tui-textarea 0.7.0 is the latest release.
Note that a runtime test for dtui cannot use the default
infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
disabled; such a test would need an armv7 or aarch64 toolchain instead.
Build tested with utils/test-pkg against:
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE
all three fail with the above error before this change and are skipped
after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
still select and build the package.
Link: https://github.com/rhysd/tui-textarea/issues/66
Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Rust does not provide 64-bit atomics on every target Buildroot can
generate. rustc sets max_atomic_width = 32 for three of the 25 targets
listed in RUST_TARGETS in utils/update-rust, so
core::sync::atomic::AtomicU64 and AtomicI64 simply do not exist there:
$ rustc --print cfg --target <target> | grep target_has_atomic
armv5te-unknown-linux-gnueabi "16" "32" "8" "ptr"
armv5te-unknown-linux-musleabi "16" "32" "8" "ptr"
powerpc-unknown-linux-gnu "16" "32" "8" "ptr"
Every other supported target, including armv6, armv7, aarch64, all the
x86 variants, riscv64, s390x, sparc64 and both 64-bit powerpcs, has
them, e.g.:
arm-unknown-linux-gnueabi "16" "32" "64" "8" "ptr"
armv7-unknown-linux-gnueabihf "16" "32" "64" "8" "ptr"
A crate that uses 64-bit atomics without a cfg(target_has_atomic = "64")
guard therefore fails to build on those three targets with:
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
|
| atomic::{AtomicU64, AtomicU8, AtomicUsize, Ordering},
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
This has been hit at least twice already: by package/dust, worked around
in commit 3abc3b97ba ("package/dust: bump to version 1.1.2") by moving
to a release in which upstream had added the guard and by package/dtui,
which has no such release available and had to open-code the affected
architectures instead.
It is likely to keep recurring: infra.basetest.BASIC_TOOLCHAIN_CONFIG
builds with BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, so
every runtime test that does not override the toolchain compiles for
armv5te, one of the three affected targets. That is exactly how the two
failures above were found.
Add a hidden symbol so packages can express this constraint once, rather
than each open-coding BR2_ARM_CPU_ARMV5 and BR2_powerpc and needing to
update whenever rust gains or changes a target.
Note that armv5te and 32-bit powerpc are only supported by rust for
glibc and musl, so the uclibc variants of those architectures are
already excluded by BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS.
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
