The 5.4.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Bump kernel version in test_zfs.py.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit 95c385e2d6 in -next
branch bumped libcamera to version 0.6.0 which breaks the build:
../core/options.cpp:405:44: error: conversion from
'std::basic_string_view<char>' to non-scalar type
'const std::string' {aka 'const std::__cxx11::basic_string<char>'}
requested
405 | const std::string cam_id =
*cameras[camera]->properties().get(libcamera::properties::Model);
Added upstream patch, included since version 1.10.0, to fix the problem.
Please note that since version 1.9.1 this package is incompatible with
the current version of ffmpeg used in buildroot so bumping it is not an
option atm:
cbe9921eed
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: fix Buildroot commit id of libcamera bump]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following security issues:
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2chttps://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
https://lists.x.org/archives/xorg-announce/2025-October/003635.html
Changelog:
https://lists.x.org/archives/xorg/2025-October/062148.html
Also update the COPYING hash for a change of copyright year.
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
[Peter: Mark as security bump, extend commit message, fix COPYING hash]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 00230e7 "package/pkg-golang: catch use of legacy FOO_INSTALL_BINS"
introduced a small typo, fixing that.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add optee_os to the default configuration for versal2 devices including an
example with the versal2_vek385_defconfig.
Since not all versal2 optee_os features are upstream, use the downstream
Xilinx release tag xlnx_rebase_v4.5.0_2025.2 for version xilinx_v2025.2
which is based on optee_os v4.5.0.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Most of the time, users will be running Vivado on their local host machine,
and will generate a XSA (Xilinx Shell Archive) locally.
Instead of requiring users to create a URL location for their XSA file,
this patch improves ease of use by allowing users to work directly with
just a path on the local host machine.
BR2_TARGET_XILINX_PREBUILT_VERSAL_XSA_LOCATION can thus be defined as either
a simple local location or a URL location for the XSA file.
In either case, a hash for the XSA file needs to be added to the
boot/xilinx-prebuilt/xilinx-prebuilt.hash when using this option.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
https://lwn.net/Articles/1049060/
"This is the LAST 5.4.y release. It is now end-of-life and should not be
used by anyone, anymore. As of this point in time, there are 1539
documented unfixed CVEs for this kernel branch, and that number will
only increase over time as more CVEs get assigned for kernel bugs."
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As requested by the gnu.org admins:
"
Since August 2024, we've been under DDoS attacks from common command line
tools.
To fix this, we would need to change the user-agent from "Python/3.11
aiohttp/3.8.4" to "buildroot.org pkg-stats" instead.
"
It indeed probably makes sense to use an unique user-agent string, so rework
the script to do that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since libcap has been updated to version 2.77 in Buildroot commit
42f2b480a5, the build fails for
statically-linked configurations when the host system doesn't have a
static version of libc installed:
/usr/bin/ld: cannot find -lc: No such file or directory
/usr/bin/ld: have you installed the static version of the c library ?
This is because the -static flag that is supposed to be used when
building target code also gets passed to the host compiler... which is
obviously incorrect and leads to the build failure.
This issue was introduced by upstream commit
c3ddf45d9afaab85d3b7db0dc7bfd1aafb8fde50, which was reverted right
after the 2.77 release in commit
542d7d86ecd2129dd5fe7e5b31ba307304f5b319, which we are simply
backporting here.
Fixes:
https://autobuild.buildroot.net/results/f6d/f6dc61a9d57e282691b87a3a8fadcb5d5ea8fd8b/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add an example config for the Versal2 VEK385 evaluation board. This board has
the superset 2VE3858 device of the Versal AI Edge Gen 2 family with
8 Cortex-A78AE cores, 10 Cortex-R52 cores, 144 AIE-ML tiles and over 500k LUTs.
With this patch, Buildroot is capable to build a full image for the VEK385
evaluation board along with all the necessary firmware components.
More information about the VEK385 evaluation board can be found here:
https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/vek385.html
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add support for Xilinx versal2 devices which include two new applications
for the xilinx-embeddedsw package.
BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL2_PLM
There is a new PLM (platform loader and manager) application for versal2
devices. The purpose of the PLM is to act as the bootloader for loading the
boot.pdi to configure the DDR memory and then loading arm-trusted-firmware and
u-boot on the Cortex-A78 core 0.
BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL2_ASUFW
Included with versal2 devices is a risc-v based security accelerator called
the ASU (application security unit). The ASUFW is the open-source application
which runs on the ASU.
Versal2 devices simplified the boot process by getting rid of the second
microblaze core called the PSM (processor system manager). There is thus no
longer a need for a separate psmfw application like with the original versal
devices, as this functionality is now fully included in the new PLM for
versal2.
For more information about the Xilinx Versal Gen2 series:
https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal/gen2/ai-edge-series.htmlhttps://www.amd.com/en/products/adaptive-socs-and-fpgas/versal/gen2/prime-series.html
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
