And adjust the dtb path to the new subdir after commit 724ba6751532 ("ARM:
dts: Move .dts files to vendor sub-directories") in v6.5.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e993272b32)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
With the change to default to gcc 14.x with commit 1e1fafa1f0
("package/gcc: switch to GCC 14.x as the default"), the old u-boot version
no longer builds:
board/ti/am57xx/board.c:948:17: error: implicit declaration of function 'do_cape_detect'; did you mean 'do_board_detect'? [-Wimplicit-function-declaration]
https://gitlab.com/buildroot.org/buildroot/-/jobs/11570241744
So move to u-boot 2025.04 to fix that. We still need a small patch as
(early) beagleboneai boards do not have the EEPROM (or eMMC partition)
populated, so include the bb.org patch from
https://github.com/beagleboard/u-boot/commit/0b161f8e89a411fe54059cf1d0ba61354ee1e8a2
The new u-boot version needs both openssl and gnutls on the host, so enable
them.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: remove patch entry in .checkpackageignore to
fix check-package error
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7ec419fb9c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The roseapplepi defconfig fails to build u-boot since the move to GCC 15.x:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11501385206
The issues are mainly related to missing includes, but given that the build
has been broken for a while, there is no mainline u-boot support for the
platform and the minimal kernel support has not seen any updates since it
was added for v5.15, just drop the defconfig.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 56091a5818)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
For release note, see:
https://docs.djangoproject.com/en/5.2/releases/5.2.7/
This fixes the following vulnerabilities:
- CVE-2025-59681:
An issue was discovered in Django 4.2 before 4.2.25, 5.1 before
5.1.13, and 5.2 before 5.2.7. QuerySet.annotate(), QuerySet.alias(),
QuerySet.aggregate(), and QuerySet.extra() are subject to SQL
injection in column aliases, when using a suitably crafted dictionary,
with dictionary expansion, as the **kwargs passed to these methods (on
MySQL and MariaDB).
https://www.cve.org/CVERecord?id=CVE-2025-59681
- CVE-2025-59682:
An issue was discovered in Django 4.2 before 4.2.25, 5.1 before
5.1.13, and 5.2 before 5.2.7. The django.utils.archive.extract()
function, used by the "startapp --template" and "startproject
--template" commands, allows partial directory traversal via an
archive with file paths sharing a common prefix with the target
directory.
https://www.cve.org/CVERecord?id=CVE-2025-59682
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: add link to release note]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7bbc66a39e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The board/versal/post-image.sh script has an unnecessary mkdir command:
mkdir -p "${BINARIES_DIR}"
This directory is created before calling the post image scripts,
in [1].
Just above the command, the script is making a symlink for the Linux DTB in
the ${BINARIES_DIR}, so if the ${BINARIES_DIR} did not already exist with
images inside, the script would fail regardless of whether this mkdir is
executed or not.
For this reason, remove the mkdir call from the script because it is not
necessary.
[1] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.08/Makefile#L829
Signed-off-by: Neal Frager <neal.frager@amd.com>
[Julien: add a link showing where the directory is created]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 018cf24c80)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerabilities:
- CVE-2024-57822:
In Raptor RDF Syntax Library through 2.0.16, there is a heap-based
buffer over-read when parsing triples with the nquads parser in
raptor_ntriples_parse_term_internal().
https://www.cve.org/CVERecord?id=CVE-2024-57822
- CVE-2024-57823:
In Raptor RDF Syntax Library through 2.0.16, there is an integer
underflow when normalizing a URI with the turtle parser in
raptor_uri_normalize_path().
https://www.cve.org/CVERecord?id=CVE-2024-57823
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e94cd21e7b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
For release note, see:
https://ghostscript.readthedocs.io/en/gs10.06.0/News.html
This fixes the following vulnerabilities:
- CVE-2025-59798:
Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow
in pdf_write_cmap in devices/vector/gdevpdtw.c.
https://www.cve.org/CVERecord?id=CVE-2025-59798
- CVE-2025-59799:
Artifex Ghostscript through 10.05.1 has a stack-based buffer overflow
in pdfmark_coerce_dest in devices/vector/gdevpdfm.c via a large size
value.
https://www.cve.org/CVERecord?id=CVE-2025-59799
- CVE-2025-59800:
In Artifex Ghostscript through 10.05.1, ocr_begin_page in
devices/gdevpdfocr.c has an integer overflow that leads to a heap-
based buffer overflow in ocr_line8.
https://www.cve.org/CVERecord?id=CVE-2025-59800
- CVE-2025-59801:
In Artifex GhostXPS before 10.06.0, there is a stack-based buffer
overflow in xps_unpredict_tiff in xpstiff.c because the
samplesperpixel value is not checked.
https://www.cve.org/CVERecord?id=CVE-2025-59801
Also remove patch that is now applied upstream, and add new patch from
upstream to fix a compilation issue on 32bits platforms
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien:
- add link to release note in commit log
- fix URL in hash file comment
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6f984089c0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerability:
- CVE-2025-8869:
When extracting a tar archive pip may not check symbolic links point
into the extraction directory if the tarfile module doesn't implement
PEP 706. Note that upgrading pip to a "fixed" version for this
vulnerability doesn't fix all known vulnerabilities that are
remediated by using a Python version that implements PEP 706. Note
that this is a vulnerability in pip's fallback implementation of tar
extraction for Python versions that don't implement PEP 706 and
therefore are not secure to all vulnerabilities in the Python
'tarfile' module. If you're using a Python version that implements PEP
706 then pip doesn't use the "vulnerable" fallback code. Mitigations
include upgrading to a version of pip that includes the fix, upgrading
to a Python version that implements PEP 706 (Python >=3.9.17,
>=3.10.12, >=3.11.4, or >=3.12), applying the linked patch, or
inspecting source distributions (sdists) before installation as is
already a best-practice.
https://www.cve.org/CVERecord?id=CVE-2025-8869
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 78d687d2d2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The web link www.zedboard.org is no longer valid as it routes to a generic
avnet.com boards link. Fix this issue by providing direct links to the Avnet
ZedBoard and Tria MicroZed boards.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4e7f03314d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
As the xilinx.com website will soon be going away, migrate all xilinx board
web links from xilinx.com to amd.com.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 74dcda2544)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
This defconfig no longer builds:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11161167596
It is still based on the 4.8.6 kernel, which is not even an LTS
kernel, so we cannot easily update to fix the issues which are most
likely due to the newer gcc/binutils versions we're using now.
There is no DEVELOPERS entry attached to this configuration as well,
and this defconfig has been broken for at least 2 months, probably
more (our Gitlab CI history is only kept for ~2 months). So let's drop
it, unles someone volunteers to resurrect it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 0590ef1a81)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
For more details on the version bump, see:
- https://gitlab.com/libtiff/libtiff/-/releases/v4.7.1
This bump includes the security fix for CVE-2025-8176, CVE-2025-8177
that were addressed in commit [1][2].
Also fixes the following vulnerabilities:
- CVE-2024-13978
A vulnerability was found in LibTIFF up to 4.7.0. It has been
declared as problematic. Affected by this vulnerability is the
function t2p_read_tiff_init of the file tools/tiff2pdf.c of the
component fax2ps. The manipulation leads to null pointer
dereference. The attack needs to be approached locally. The
complexity of an attack is rather high. The exploitation appears to
be difficult. The patch is named
2ebfffb0e8836bfb1cd7d85c059cd285c59761a4. It is recommended to apply
a patch to fix this issue.
For more information, see:
- https://nvd.nist.gov//vuln/detail/CVE-2024-13978
- https://gitlab.com/libtiff/libtiff/-/commit/2ebfffb0e8836bfb1cd7d85c059cd285c59761a4
- CVE-2025-8961
A weakness has been identified in LibTIFF 4.7.0. This affects the
function main of the file tiffcrop.c of the component tiffcrop.
Executing manipulation can lead to memory corruption. The attack can
only be executed locally. The exploit has been made available to the
public and could be exploited.
For more information, see:
- https://nvd.nist.gov//vuln/detail/CVE-2025-8961
- https://gitlab.com/libtiff/libtiff/-/commit/0ac97aa7a5bffddd88f7cdbe517264e9db3f5bd5
- CVE-2025-9165
A flaw has been found in LibTIFF 4.7.0. This affects the function
_TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the
file tools/tiffcmp.c of the component tiffcmp. Executing
manipulation can lead to memory leak. The attack is restricted to
local execution. The exploit has been published and may be used.
This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is
best practice to apply a patch to resolve this issue.
For more information, see:
- https://nvd.nist.gov//vuln/detail/CVE-2025-9165
- https://gitlab.com/libtiff/libtiff/-/commit/ed141286a37f6e5ddafb5069347ff5d587e7a4e0
This commit also updates the LICENSE.md hash file, which was updated
upstream to include a historical license. See:
https://gitlab.com/libtiff/libtiff/-/commit/a0b623c7809ea2aa4978d5d7b7bd10e519294c78
[1] b3974df966 package/tiff: add patches to fix CVE-2025-8176
[2] 3db725d71d package/tiff: add patch to fix CVE-2025-8177
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Julien: fix license hash]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9e67ae519f)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
AMD / Xilinx has made the decision to change the name of plm.elf to plmfw.elf
in the prebuilt binaries repo starting with the next update.
This patch updates the xilinx-prebuilt package to support either the old
plm.elf filename or the new plmfw.elf filename.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6f435187c6)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Migrate the BR2_TARGET_UBOOT_ZYNQMP dependency to the new
BR2_TARGET_XILINX_FIRMWARE_ARCH_SUPPORTS symbol. Also, add a cpu dependency
on BR2_cortex_a53 since the zynqmp platform is based on the ARM Cortex-A53
and the BR2_TARGET_UBOOT_ZYNQMP should not be available for other CPUs with
aarch64 architecture.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5986c51219)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Add an architecture cpu dependency to each family to make sure that users can
only install prebuilt firmware which is applicable to their target device
family.
The versal family is based on BR2_cortex_a72.
The kria and zynqmp families are based on BR2_cortex_a53.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 92f76f6c35)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Add an architecture cpu dependency to each application to make sure that users
can only build applications which are applicable to their target device
family.
The versal_plm and versal_psmfw applications are specific to versal devices
which are based on BR2_cortex_a72.
The zynqmp_pmufw application is specific to zynqmp devices which are based on
BR2_cortex_a53.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9e25bcfdab)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Currently, the xilinx-embeddedsw and xilinx-prebuilt packages are appearing
for any aarch64 processor. As all Xilinx processors that need these packages
are ARM Cortex-A53 or ARM Cortex-A72, this means that these packages are
often appearing as options for non-Xilinx platforms.
To reduce this occurrence, this patch creates a new symbol
BR2_TARGET_XILINX_FIRMWARE_ARCH_SUPPORTS to limit the appearance of the
xilinx-embeddedsw and xilinx-prebuilt boot packages to only platforms based
on the BR2_cortex_a53 or BR2_cortex_a72 CPU and aarch64 architecture.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5b1a52aea0)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Patches submitted to update these packages have gone ignored for
months without comment, and I no longer wish to recieve daily
emails about them being out of date.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 20f99312c9)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
This removes a warning reported by shellcheck: "Double quote to prevent
globbing and word splitting". As a result, the file can be removed from
.checkpackageignore.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e7937c52b6)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
The elfutils package provides libdw, which is required by sysprof.
It is not an optional dependency.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 194a6e0391)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Some links are still pointing to git.buildroot.org, which is the old URL
for the official Buildroot git repository. The repository is now hosted
at gitlab.com. Update those old links accordingly.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3ae80441ed)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
See the release notes:
- https://github.com/OpenPrinting/cups/releases/tag/v2.4.13
- https://github.com/OpenPrinting/cups/releases/tag/v2.4.14
This fixes the following vulnerabilities:
- CVE-2025-58060:
OpenPrinting CUPS is an open source printing system for Linux and
other Unix-like operating systems. In versions 2.4.12 and earlier,
when the `AuthType` is set to anything but `Basic`, if the request
contains an `Authorization: Basic ...` header, the password is not
checked. This results in authentication bypass. Any configuration that
allows an `AuthType` that is not `Basic` is affected. Version 2.4.13
fixes the issue.
https://www.cve.org/CVERecord?id=CVE-2025-58060
- CVE-2025-58364:
OpenPrinting CUPS is an open source printing system for Linux and
other Unix-like operating systems. In versions 2.4.12 and earlier, an
unsafe deserialization and validation of printer attributes causes
null dereference in the libcups library. This is a remote DoS
vulnerability available in local subnet in default configurations. It
can cause the cups & cups-browsed to crash, on all the machines in
local network who are listening for printers (so by default for all
regular linux machines). On systems where the vulnerability
CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was
not fixed, and the firewall on the machine does not reject incoming
communication to IPP port, and the machine is set to be available to
public internet, attack vector "Network" is possible. The current
versions of CUPS and cups-browsed projects have the attack vector
"Adjacent" in their default configurations. Version 2.4.13 contains a
patch for CVE-2025-58364.
https://www.cve.org/CVERecord?id=CVE-2025-58364
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 89fd61a127)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
When searching for the official git repository in the documentation,
readers are forwarded to the buildroot website Download page with a link
pointing to buildroot.org/download, which returns a 404.
Fix the dead link by adding the missing .html suffix.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8845586fc6)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
The CMake build system has logic to detect the git repo info and include it
in the version output. This unfortunately gets confused and adds the git
info of the Buildroot repository when building inside the repo:
-- Found Git version: refs/heads/rtl_433-25.02 commit a367362af0 from 2025-09-21T20:07:58+0200
-- Using Git version tag: 2025.08-283-ga367362af0 on rtl_433-25.02 at 202509212007
rtl_433 -V
rtl_433 version 2025.08-283-ga367362af0 branch rtl_433-25.02 at 202509212007 inputs file rtl_tcp RTL-SDR
Pass GIT_DIR=. to the configure step similar to how it is already done for
the build step to disable this.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 817611686a)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Build fails with:
server.c: In function 'ServerDaemonize':
server.c:1590:13: error: implicit declaration of function 'fork'
[-Wimplicit-function-declaration]
1590 | switch (fork()) {
| ^~~~
Hence, add BR2_USE_MMU to avoid building with toolchains without MMU
support.
Fixes:
https://autobuild.buildroot.org/results/10464159f2a9ff41ea0921a45ce12ecd0fa50ae7/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
[Julien: move BR2_USE_MMU up to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 059138326e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
TestGitHash and TestGitRefs are failing on Gitlab-CI since 2025-08-18
(first runtime-test failures report for master) [1] due a new Gitlab-CI
security settings that prevents the any use of localhost (127.0.0.1) on
the Gitlab-CI runner [2]:
"To prevent exploitation of insecure internal web services, all webhook
and integration requests to the following local network addresses are
not allowed:
Private network addresses, including 127.0.0.1, ::1, 0.0.0.0,
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and IPv6 site-local
(ffc0::/10) addresses."
Gitlab suggest using a second container as a Services [3] since each
containers have access to one another and can communicate when running
the job. But this is really not practical to run git daemon since the
service is started before the Buildroot git tree is fetched and git
daemon needs git-remote directory content.
See [4]:
"If you have your service that tries to write to CI_PROJECT_DIR
immediately after it's started - it will not work and fail with an
error like '/builds/nknapp/gitlab-ci-test/': No such file or directory
error. Because that directory is most probably not there yet, as the
job step that creates it is yet to be executed!"
Also, using Gitlab-CI services requires to handle GitTestBase setUp
differently on Gitlab-CI than local use of run-tests.
So Gitlab-CI services is not an option.
We could move support/testing/tests/download/git-remote to our Gitlab
group (https://gitlab.com/buildroot.org) but since it's only intended
for testing the git download backend, we don't really want to do that.
So the only remaining choice to clone the repository from the Buildroot
git tree (local machine).
To do so, we have to do the following changes:
- Replace all "git://localhost:$(GITREMOTE_PORT_NUMBER)" by
"$(GITREMOTE_DIR)". GITREMOTE_DIR will contain the absolute path to
tests/download/git-remote directory.
- Force to use git download backend using "SITE_METHOD = git" otherwise
the download infra will fall back using wget download backend.
- Cloning a git repository with submodules using the "file://" protocol
needs to be allowed from git config. It's disabled by default:
"fatal: transport 'file' not allowed"
Use a local gitconfig file generated by GitTestBase before starting
TestGitHash and TestGitRefs with:
[protocol "file"]
allow = always
This is considered safe since we are using a git repository from the
Buildroot git tree.
- Running TestGitHash and TestGitRefs on Gitlab-CI requires additional
git config settings to disable ownership check of the git tree [5].
Thanks to Arnout for advices about GIT_CONFIG_GLOBAL.
Runtime tested:
https://gitlab.com/kubu93/buildroot/-/jobs/11428504450 (TestGitHash)
https://gitlab.com/kubu93/buildroot/-/jobs/11428490035 (TestGitRefs)
[1] https://lore.kernel.org/buildroot/68a3ee65.500a0220.397724.30db@mx.google.com/
[2] https://docs.gitlab.com/security/webhooks/#allow-requests-to-the-local-network-from-webhooks-and-integrations
[3] https://docs.gitlab.com/ci/services/
[4] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25982#note_2139685797
[5] https://gitlab.com/buildroot.org/buildroot/-/commit/a016b693f7830f3c8ae815851d3204b8b6e99821
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124174 (TestGitHash)
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124173 (TestGitRefs)
Cc: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a367362af0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Finally the aarch64 tls bug is fixed. (python 3.13 segfault)
Unfortunately it is not covered by any testcase of uClibc-ng-test.
Here is the git shortlog for the release:
Marius Melzer (1):
malloc-standard: Fix truncation problem in malloc
Waldemar Brodkorb (5):
Fix Sysvipc for ARM, AARCH64, RISCV64, KVX and m68k
remove uClibc specific gettext_printf
aarch64: do not force tls-model in CPU_CFLAGS, this isn't required
aarch64: respect r_addend for TLSDESC relocations
bump version for 1.0.55 release
yliu (5):
mips32: Preventing FORCE_FRAME_POINTER from being optimized away
mips32: Define __IPC_64 according to kernel version
time64: fixed msgctl/semctl/shmctl result errors for for MIPS32/RISCV32
time64: fix *ctl functions in mips32eb/mips64
time64: fix *ctl functions in mips32eb
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5250bba8e5)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerability:
- CVE-2025-6375:
A vulnerability was found in poco up to 1.14.1. It has been rated as
problematic. Affected by this issue is the function MultipartInputStream
of the file Net/src/MultipartReader.cpp. The manipulation leads to null
pointer dereference. The attack needs to be approached locally. The
exploit has been disclosed to the public and may be used. Upgrading to
version 1.14.2 is able to address this issue. The patch is identified as
6f2f85913c191ab9ddfb8fae781f5d66afccf3bf. It is recommended to upgrade
the affected component.
For more information see:
- https://nvd.nist.gov//vuln/detail/CVE-2025-6375
- https://github.com/pocoproject/poco/commit/6f2f85913c191ab9ddfb8fae781f5d66afccf3bf
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 36357247d5)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security issue:
CVE-2025-8713: PostgreSQL optimizer statistics can expose sampled data
within a view, partition, or child table
PostgreSQL optimizer statistics allow a user to read sampled data within
a view that the user cannot access. Separately, statistics allow a user
to read sampled data that a row security policy intended to hide.
PostgreSQL maintains statistics for tables by sampling data available in
columns; this data is consulted during the query planning process. Prior
to this release, a user could craft a leaky operator that bypassed view
access control lists (ACLs) and bypassed row security policies in
partitioning or table inheritance hierarchies. Reachable statistics data
notably included histograms and most- common-values lists. CVE-2017-7484
and CVE-2019-10130 intended to close this class of vulnerability, but
this gap remained. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19,
and 13.22 are affected.
CVE-2025-8714: PostgreSQL pg_dump lets superuser of origin server execute
arbitrary code in psql client
Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious
superuser of the origin server to inject arbitrary code for restore-time
execution as the client operating system account running psql to restore
the dump, via psql meta-commands. pg_dumpall is also affected. pg_restore
is affected when used to generate a plain-format dump. This is similar to
MySQL CVE-2024-21096. Versions before PostgreSQL 17.6, 16.10, 15.14,
14.19, and 13.22 are affected.
CVE-2025-8715: PostgreSQL pg_dump newline in object name executes
arbitrary code in psql client and in restore target server
Improper neutralization of newlines in pg_dump in PostgreSQL allows a user
of the origin server to inject arbitrary code for restore-time execution
as the client operating system account running psql to restore the dump,
via psql meta-commands inside a purpose-crafted object name. The same
attacks can achieve SQL injection as a superuser of the restore target
server. pg_dumpall, pg_restore, and pg_upgrade are also affected.
Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.
Versions before 11.20 are unaffected. CVE-2012-0868 had fixed this class
of problem, but version 11.20 reintroduced it.
https://www.postgresql.org/about/news/postgresql-176-1610-1514-1419-1322-and-18-beta-3-released-3118/
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4f0a9596e3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
While doing a per-package build the package is failing to
compile with this error (gcc 13.x glibc toochain):
make[3]: Entering directory
'/home/wbx/buildroot-2025.02.3/output/build/xapp_xdm-1.1.14/xdm' CC
session.o session.c:146:11: fatal error: crypt.h: No such file or
directory 146 | # include <crypt.h> | ^~~~~~~~~
compilation terminated.
Fix this error by providing the needed glibc dependencies.
Fixes:
https://autobuild.buildroot.org/results/b75/b75ad8f1159613656dce482992c800545d60ae69/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2d076a1b76)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Add a patch fixing prototype issues with GCC 15.x. The patch cannot be
submitted upstream because the problematic code has completely changed
in newer releases.
No autobuilder failures because they were hidden by 'c-icap' not
building with GCC 15.x.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2febca71f7)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Take two patches from the Debian jxrlib package, and integrate them to
fix the build of the bundled jxrlib library found in the libfreeimage
package.
libfreeimage isn't exactly well maintained: its last version 3.18.0 is
quite old (July 2018), there's a fairly large number of tickets in the
bug tracker claiming to be CVE
reports (https://sourceforge.net/p/freeimage/bugs/), it is still using
SVN as the version control system.
However, it is used as an optional dependency for CEGUI, and a
mandatory dependency for Ogre. However, it no longer seems to be a
dependency for more recent versions of Ogre. But in any case it cannot
simply be dropped.
Fixes:
https://autobuild.buildroot.net/results/452462285bf93b13f092fb41696952f415e75b2f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 21ea33c764)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerability:
- CVE-2025-8835:
A vulnerability was found in JasPer up to 4.2.5. Affected by this
vulnerability is the function jas_image_chclrspc of the file
src/libjasper/base/jas_image.c of the component Image Color Space
Conversion Handler. The manipulation leads to null pointer dereference.
It is possible to launch the attack on the local host. The exploit has
been disclosed to the public and may be used. The identifier of the
patch is bb7d62bd0a2a8e0e1fdb4d603f3305f955158c52. It is recommended to
apply a patch to fix this issue.
For more information see:
- https://nvd.nist.gov//vuln/detail/CVE-2025-8835
- https://github.com/jasper-software/jasper/commit/bb7d62bd0a2a8e0e1fdb4d603f3305f955158c52
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6e81b51f68)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This CVE is specific for the version 5.1.5 still present in Buildroot.
It has been fixed in 5.2.3 and thereby doesn't affects the other
versions available in Buildroot.
- CVE-2014-5461
Buffer overflow in the vararg functions in ldo.c in Lua 5.1 through
5.2.x before 5.2.3 allows context-dependent attackers to cause a denial
of service (crash) via a small number of arguments to a function with a
large number of fixed arguments.
For more information see:
- https://security-tracker.debian.org/tracker/CVE-2014-5461
- https://udd.debian.org/patches.cgi?src=lua5.1&version=5.1.5-11
A patch present in Debian is used to address this vulnerability.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a2c906ee3b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerability:
- CVE-2025-53644:
OpenCV is an Open Source Computer Vision Library. Versions prior to
4.12.0 have an uninitialized pointer variable on stack that may lead
to arbitrary heap buffer write when reading crafted JPEG images.
Version 4.12.0 fixes the vulnerability.
https://www.cve.org/CVERecord?id=CVE-2025-53644
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9c365fee97)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The CPE 'iputils_project:iputils' has been deprecated in favour of
'iputils:iputils'.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4ac3c1de56)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
policycoreutils uses getpass(), which with musl is only defined with
some feature macro defined, such as _GNU_SOURCE. So let's pick-up an
upstream fix to address this issue.
There are no autobuilder failures, the issue was most likely hidden by
other failures with musl affecting the SELinux stack.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fc472cc8c7)
[thomas: fix patch]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The build of libsemanage on musl configurations fails with:
direct_api.c: In function 'semanage_direct_install_file':
direct_api.c:1746:20: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
1746 | filename = basename(path);
| ^~~~~~~~
This fails to build even with a GCC 14.x toolchain, even with
libsemanage 3.7, which is the version we have in our LTS branch.
Let's backport an upstream patch fixing this issue.
Fixes:
https://autobuild.buildroot.net/results/913852e35c925888ced37e15be3731b9d3963019/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 79031b79c2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Luvi 2.14.0 fails to build with GCC 14.x for several reasons due to
too old lua-openssl 0.8.2-0 submodule:
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c: In function 'openssl_ocsp_request_read':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c:124:29: error: passing argument 1 of 'PEM_ASN1_read_bio' from incompatible pointer type [-Wincompatible-pointer-types]
124 | OCSP_REQUEST *req = pem ? PEM_read_bio_OCSP_REQUEST(bio, NULL, NULL)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| char * (*)()
Fixed in lua-openssl by [1].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c: In function 'openssl_push_general_name':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c:377:45: error: passing argument 2 of 'openssl_push_asn1type' from incompatible pointer type [-Wincompatible-pointer-types]
377 | openssl_push_asn1type(L, general_name->d.x400Address);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~
| |
| ASN1_STRING * {aka struct asn1_string_st *}
Fixed in lua-openssl by [2].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/openssl.c: In function 'luaclose_openssl':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/stdatomic.h:387:9: error: implicit declaration of function '__c11_atomic_fetch_sub'; did you mean '__atomic_fetch_sub'? [-Wimplicit-function-declaration]
387 | __c11_atomic_fetch_sub(object, operand, order)
Fixed in lua-openssl by [3].
Instead of fixing one by one each issues, update to the latest release
that include lua-openssl 0.9.0-0. Luvi v2.15.0 still have some GCC 14.x
issues, backport two additional patches.
Download luvi sources using git method since the release archive
no longer include the release version in its name [4].
Luvi switched to PCRE2 [5], update the optional dependency.
Update TestLuvi to select PCR2 package.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124430 (TestLuvi)
[1] https://github.com/zhaozg/lua-openssl/commit/bfeedbe8c06d8b4400fa670edecd452a433ddac4
[2] https://github.com/zhaozg/lua-openssl/commit/e5b5420cc506c7507d1d0e7302ea3f1979a6b2ed
[3] https://github.com/zhaozg/lua-openssl/commit/cfcaa16d1acaab17f4f0178e61ea77ebc2c8f24c
[4] https://github.com/luvit/luvi/releases/download/v2.15.0/luvi-source.tar.gz
[5] https://github.com/luvit/luvi/releases/tag/v2.15.0
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 00317f0aff)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
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>
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] https://github.com/slimm609/checksec/commit/1c80e39c4956f902ed15c4baa8d9c17851096900
[3] https://github.com/slimm609/checksec/commit/1c80e39c4956f902ed15c4baa8d9c17851096900#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:
https://github.com/Xilinx/linux-xlnx/commit/9691533f6e6fd0a596ac7688e82eeea53f22c434
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>
Fixes https://autobuild.buildroot.net/results/f32ae62961aac7e8344f4be109040e7de2eb415e/
The openssl logic in ecryptfs uses the openssl engines API, which is always
available in libressl, but only available in libopenssl when
BR2_PACKAGE_LIBOPENSSL_ENGINES is enabled, leading to build failures when it
is not:
ecryptfs_key_mod_openssl.c: In function 'ecryptfs_openssl_read_key':
ecryptfs_key_mod_openssl.c:305:9: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
305 | ENGINE_load_builtin_engines();
Fix it by only passing --enable-openssl if libressl or (libopenssl + engines
support) is enabled.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes https://autobuild.buildroot.net/results/9d4e2f156d76e2acc83e3a25adb5e5cf0705e7c6/
configure:781: checking whether the C compiler (/home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 ) works
configure:797: /home/buildroot/instance-0/output-1/host/bin/armeb-buildroot-linux-gnueabi-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -D_FORTIFY_SOURCE=1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c 1>&5
configure:794:1: error: return type defaults to 'int' [-Wimplicit-int]
794 | main(){return(0);}
| ^~~~
configure: failed program was:
#line 792 "configure"
#include "confdefs.h"
main(){return(0);}
Wipe uses a very old configure script where the compile checks are missing
the return type on main(), breaking the configure step with >= gcc-15.
As a workaround, use AUTORECONF to regenerate the configure script.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a major version bump, because it could break user code that depends
on the (wrong) previous logic fixed by the new release
See the release notes:
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.0
- https://github.com/corydolphin/flask-cors/releases/tag/6.0.1
This fixes the following vulnerabilities:
- CVE-2024-6839:
corydolphin/flask-cors version 4.0.1 contains an improper regex path
matching vulnerability. The plugin prioritizes longer regex patterns
over more specific ones when matching paths, which can lead to less
restrictive CORS policies being applied to sensitive endpoints. This
mismatch in regex pattern priority allows unauthorized cross-origin
access to sensitive data or functionality, potentially exposing
confidential information and increasing the risk of unauthorized
actions by malicious actors.
https://www.cve.org/CVERecord?id=CVE-2024-6839
- CVE-2024-6844:
A vulnerability in corydolphin/flask-cors version 4.0.1 allows for
inconsistent CORS matching due to the handling of the '+' character in
URL paths. The request.path is passed through the unquote_plus
function, which converts the '+' character to a space ' '. This
behavior leads to incorrect path normalization, causing potential
mismatches in CORS configuration. As a result, endpoints may not be
matched correctly to their CORS settings, leading to unexpected CORS
policy application. This can cause unauthorized cross-origin access or
block valid requests, creating security vulnerabilities and usability
issues.
https://www.cve.org/CVERecord?id=CVE-2024-6844
- CVE-2024-6866:
corydolphin/flask-cors version 4.01 contains a vulnerability where the
request path matching is case-insensitive due to the use of the
`try_match` function, which is originally intended for matching hosts.
This results in a mismatch because paths in URLs are case-sensitive,
but the regex matching treats them as case-insensitive. This
misconfiguration can lead to significant security vulnerabilities,
allowing unauthorized origins to access paths meant to be restricted,
resulting in data exposure and potential data leaks.
https://www.cve.org/CVERecord?id=CVE-2024-6866
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerabilities:
- CVE-2023-5341:
A heap use-after-free flaw was found in coders/bmp.c in ImageMagick.
https://www.cve.org/CVERecord?id=CVE-2023-5341
- CVE-2025-55004:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, ImageMagick is
vulnerable to heap-buffer overflow read around the handling of images
with separate alpha channels when performing image magnification in
ReadOneMNGIMage. This can likely be used to leak subsequent memory
contents into the output image. This issue has been patched in version
7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55004
- CVE-2025-55005:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to version 7.1.2-1, when preparing
to transform from Log to sRGB colorspaces, the logmap construction
fails to handle cases where the reference-black or reference-white
value is larger than 1024. This leads to corrupting memory beyond the
end of the allocated logmap buffer. This issue has been patched in
version 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55005
- CVE-2025-55160:
ImageMagick is free and open-source software used for editing and
manipulating digital images. Prior to versions 6.9.13-27 and 7.1.2-1,
there is undefined behavior (function-type-mismatch) in splay tree
cloning callback. This results in a deterministic abort under UBSan
(DoS in sanitizer builds), with no crash in a non-sanitized build.
This issue has been patched in versions 6.9.13-27 and 7.1.2-1.
https://www.cve.org/CVERecord?id=CVE-2025-55160
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following vulnerability:
- CVE-2025-6965:
There exists a vulnerability in SQLite versions before 3.50.2 where
the number of aggregate terms could exceed the number of columns
available. This could lead to a memory corruption issue. We recommend
upgrading to version 3.50.2 or above.
https://www.cve.org/CVERecord?id=CVE-2025-6965
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though this is not mentioned in the release notes:
- https://github.com/containers/netavark/releases/tag/v1.16.0
- https://github.com/containers/netavark/releases/tag/v1.16.1
According to https://bugzilla.redhat.com/show_bug.cgi?id=2383941,
the fix for the CVE has been merged upstream, and is in netavark
since v1.16.0.
This fixes the following vulnerability:
- CVE-2025-8283:
A vulnerability was found in the netavark package, a network stack for
containers used with Podman. Due to dns.podman search domain being
removed, netavark may return external servers if a valid A/AAAA record
is sent as a response. When creating a container with a given name,
this name will be used as the hostname for the container itself, as
the podman's search domain is not added anymore the container is using
the host's resolv.conf, and the DNS resolver will try to look into the
search domains contained on it. If one of the domains contain a name
with the same hostname as the running container, the connection will
forward to unexpected external servers.
https://www.cve.org/CVERecord?id=CVE-2025-8283
Also bump package/aardvark-dns in the same lockstep, as advised in
the packages .mk version comments.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GCC-15 defaults to C23, which changes the meaning of an empty parameter
list:
https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters
Leading to a build failure:
tsserve.c: In function ‘set_child_exit_handler’:
tsserve.c:2988:21: error: assignment to ‘__sighandler_t’ {aka ‘void (*)(int)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
2988 | action.sa_handler = on_child_exit;
Add a patch from an upstream PR to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 0d643a8636 which removed the
BR2_PACKAGE_LIGHTTPD_LIBEV symbol was originally meant for next and
therefore introduced the "Legacy options removed in 2025.11" comment.
However, in the end it was still applied to master for 2025.08, so the
legacy symbol was incorrectly placed.
Fix that.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The github repo was deleted and moved to codeberg, so use that instead:
https://lwn.net/Articles/926101/
It is unclear if the auto generated tarballs from codeberg are reproducible,
so instead fetch through git.
[Peter: set _CPE_ID_VERSION to the correct value]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bufix release fixing a number of issues:
- Bug 5352: Do not get stuck in RESPMOD after pausing peer read(2)
- Bug 5489: Fix "make check" linking on Solaris
- Fix SNMP cacheNumObjCount -- number of cached objects
- Do not duplicate received Surrogate-Capability in sent requests
- Fix Mem::Segment::open() stub to fix build without shm_open()
- ... and CI and documentation updates
https://github.com/squid-cache/squid/releases/tag/SQUID_6_14
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since Buildroot commit [1] updating qemu defconfigs from Kernel 6.6.32
to 6.12.9, qemu_aarch64_ebbr_defconfig, qemu_aarch64_sbsa_defconfig
and qemu_arm_ebbr_defconfig can fail to build with error:
/bin/sh: 1: python3: not found
make[7]: *** [drivers/gpu/drm/msm/Makefile:182: drivers/gpu/drm/msm/generated/a2xx.xml.h] Error 127
The issue can happen on build hosts without Python, and if the Linux
kernel is built before any package having host-python3 in its
dependencies (e.g. host-qemu, optee-os, ...).
Starting with Linux 6.10, the arm and arm64 architecture defconfigs need
python3 to build. [2]
This commit fixes this issue by adding
BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3=y in those defconfigs.
[1] https://gitlab.com/buildroot.org/buildroot/-/commit/44075c19555df409ea7c2859729abb02d341df29
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=0fddd045f88e34d6160785a3a5e506d374566454
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Romain Naour <romain.naour@gmail.com>
[Julien:
- reword commit log to add the commit introducing the issue
- fix qemu_aarch64_sbsa_defconfig which has the same issue
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch fixes the CPE ID for both go-bin and go-src packages.
The go-src package did had a CPE ID because GO_SRC_CPE_ID_VENDOR is
defined but the generated CPE ID would be the following:
cpe:2.3:a:golang:go-src:*:*:*:*:*:*:*:*
The CPE product go-src doesn't match to anything and should be 'go'
instead.
For go-bin no CPE_ID variable were defined so no CPE ID would be
generated if using a pre-build toolchain.
This patch duplicate the definition of the CPE_ID variables, I didn't
put the definition in the 'package/go/go.mk' file to avoid generate a
CPE for the go virtual package.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes: https://autobuild.buildroot.net/results/9c40c86a42882a6d56eb6d6d1418781a980b6f8f/
The pthread support uses pthread_atfork(), which is not available on nommu:
cap-ng.c: In function 'init_lib':
cap-ng.c:225:9: error: implicit declaration of function 'pthread_atfork';
did you mean 'pthread_join'? [-Wimplicit-function-declaration]
So disable pthread support on nommu to fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Setting the "update" field in the CPE ID to * doesn't actually make
much sense, as * is a wildcard. Instead, this field should really
reflect the "subrelease" / "update" of the package, which unless
specified explicitly by the package .mk file, is empty.
Using a wildcard causes a few CVEs to be incorrectly identified as
affecting some of our packages.
For example https://nvd.nist.gov/vuln/detail/CVE-2013-1428 has a
CPE configuration that goes like this:
cpe:2.3:a:tinc-vpn:tinc:*:pre6:*:*:*:*:*:* up to including 1.1
and this CPE configuration is currently identified as affecting our
package. This isn't correct as our package is using 1.0.36, not a
"pre6" version. But because the CPE ID generated by Buildroot uses *
as the "update" field, and * is the wildcard, it does match with this
CPE configuration.
After this change, two CVEs are no longer identified as affecting
Buildroot packages:
https://nvd.nist.gov/vuln/detail/CVE-2013-1428https://nvd.nist.gov/vuln/detail/CVE-2017-9454
and in both cases they are indeed CVEs not affecting our package.
Reported-by: Titouan Christophe <titouan.christophe@mind.be>
Cc: Titouan Christophe <titouan.christophe@mind.be>
Cc: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Fixes: https://autobuild.buildroot.net/results/8d14173f31922a737c326be75aa24c9f9471342a/
The vde2 source code uses empty argument function pointer prototypes like:
typedef ssize_t (* ssize_fun)();
extern ssize_fun vdehist_vderead;
In C17 and earlier, such prototypes means unknown number of arguments,
whereas with C23 it means no arguments, leading to build failures:
libvdehist.c:39:27: error: initialization of 'ssize_fun' {aka 'long int
(*)(void)'} from incompatible pointer type 'ssize_t (*)(int, void *,
size_t)' {aka 'long int (*)(int, void *, long unsigned int)'}
[-Wincompatible-pointer-types]
Workaround it using -std=gnu99. Vde2 is provided both as a host and target
package, so do this unconditionally for both.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Now that the qspi.bin file is included for zynqmp images, the 32M vfat
partition is getting dangerously close to being full.
In the process of bumping Linux kernel 6.12.10 to 6.12.40, the size of the
default Linux kernel Image file for zynqmp products is increasing from 23.4M
to 26.9M. This is leaving less than 1M of 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>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This tool helps to update Linux stable releases.
The script uses the versions found in linux/linux.hash. For each of the
versions it downloads the related hash list and tries to find an updated
stable release. If found it updates all related files and hashes.
Signed-off-by: Gero Schwäricke <gero.schwaericke@grandcentrix.net>
[Arnout: commonalize the sed expression for linux and linux-headers]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Unbound is vulnerable to CVE-2025-5994: "Cache poisoning via the ECS-enabled
Rebirthday Attack" if built with --enable-subnet, which is not the case in
Buildroot, so mark it as not applicable.
https://nlnetlabs.nl/downloads/unbound/CVE-2025-5994.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit fecc337d21,
re-adding optional support for pulseuadio in ffmpeg.
This is possible now that the circular dependency:
pulseaudio -> libsoxr -> ffmpeg -> pulseaudio
has been broken between libsoxr and ffmpeg.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Having support for ffmpeg in libsoxr causes several circular
dependencies:
- pulseaudio -> libsoxr -> ffmpeg -> pulseaudio
(This one was worked around in
fecc337d21 by dropping the ffmpeg ->
pulseaudio dependency, but it's annoying as being able to output
audio from ffmpeg into pulseaudio seems useful)
- libopenmpt -> pulseaudio -> libsoxr -> ffmpeg -> libopenmpt
(This is one exists, and is fixed by this commit)
To fix both circular dependencies, we propose to drop the dependency
of libsoxr on ffmpeg, which is used to get some optimized FFT
implementation. While not being useless, this is the point where
breaking the dependency seems the most logical.
Neither Debian nor Fedora build libsoxr with ffmpeg support.
In order to achieve that, we add a new patch making the option
WITH_AVFFT actually effective. Since we no longer build against
ffmpeg, the previously added patch that was fixing the pkg-config file
is no longer needed.
Fixes:
https://autobuild.buildroot.net/results/bbfce69f35cafd56245ebeae79086a8b64592a16/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A missing include causes a build failure with GCC 15.x. There are no
known autobuilder failures for this issue, but the following defconfig
allows to reproduce the issue:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_WEBRTC_AUDIO_PROCESSING=y
# BR2_TARGET_ROOTFS_TAR is not set
The affected code has completely changed in newer versions of
webrtc-audio-processing, so we add a non-upstream patch, which can be
dropped once we upgrade to a newer release.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This host package was only used as a build dependency of libsvgtiny,
which itself has been removed, so it can be dropped as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package hasn't been updated in years. It has new releases, such
as 1.0.8 from December 2023, but nobody updated to it.
Doing the version bump is not straightforward, and the original
package submitter, Peter Korsgaard, is no longer using it. This
package also had no reverse dependency, and no maintainer in the
DEVELOPERS file.
Therefore, let's drop this package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Peter: Add Config.in.legacy handling]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The new package_dir element contains the path of the package
directory. For Buildroot packages this is a path relative to the main
Buildroot directory, for packages from external trees an absolute
path.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Tested-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building the column store plugin (which gets automatically enabled
when Boost with a bunch of submodules is found) currently fails as it
requires a number of runtime checks that obviously cannot work when
cross-compiling.
OpenEmbedded has defined them as such:
-DLSTAT_FOLLOWS_SLASHED_SYMLINK_EXITCODE=0 \
-DSTAT_EMPTY_STRING_BUG_EXITCODE=0 \
-DMASK_LONGDOUBLE_EXITCODE=0 \
but it really isn't clear whether those values are completely correct
for all CPU architectures, especially the last one.
So instead, let's disable the column store plugin until someone
actually needs it and figures out how to set those variables properly.
The issue fixed by this commit can be reproduced using the following
defconfig:
BR2_aarch64=y
BR2_ARM_FPU_VFPV3D16=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_MARIADB=y
BR2_PACKAGE_MARIADB_SERVER=y
BR2_PACKAGE_BOOST=y
BR2_PACKAGE_BOOST_DATE_TIME=y
BR2_PACKAGE_BOOST_FILESYSTEM=y
BR2_PACKAGE_BOOST_REGEX=y
BR2_PACKAGE_BOOST_THREAD=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Config.in comment is between the main BR2_PACKAGE_MARIADB option
and its sub-options, causing the sub-options to not appear as nicely
indented in menuconfig.
Before:
[ ] mariadb
[ ] mariadb server
[ ] mariadb embedded server
After:
[ ] mariadb
[ ] mariadb server
[ ] mariadb embedded server
which is what we want.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Recently when trying to reproduce a build error with test-pkg on the toolchain
br-arm-basic, I had to create a new CSV file with that toolchain only to be
able to run the test in that single case.
I believe having a command-line option right away in test-pkg would make this
much easier, as I can now run: `./utils/test-pkg -T br-arm-basic -p redis`
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
In order to remove thttpd package from Buildroot, we have to replace it
from our testsuite (TestWget and TestLibCurl).
Busybox provide an httpd server applet but it's not enabled in our
default busybox configuration.
For the sake of those tests, add a new busybox option to build and
install the Busybox's httpd server and its init script.
Import S90thttpd from thttpd package to S90httpd but with some changes
following S01syslogd init script as a reference [1].
[1] https://gitlab.com/buildroot.org/buildroot/-/commit/3dc80614442cc3942a372a8c31abd22c1bc96241
Cc: Julien Olivain <ju.o@free.fr>
Cc: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since Buildroot commit [1] dc0f7215c6 "package/gcc: switch to 13.x as
default", sipeed_licheepi_zero_defconfig fails when building the Linux
kernel with the error message:
drivers/ata/libahci.c: In function 'ahci_led_store':
./include/linux/compiler.h:350:45: error: call to '__compiletime_assert_1138' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
This issue is fixed by upstream Kernel commit [2].
This commit fixes this issue by updating the Linux Kernel from v5.3.5
(which is not a LTS series) to v6.12.43 (which is a LTS series
including the fixes). With this update,
BR2_LINUX_KERNEL_INTREE_DTS_NAME is updated accordingly to follow the
new DTS organization.
This commit also updates U-Boot from 2022.01 to 2025.07. This new
version now requires BR2_TARGET_UBOOT_NEEDS_GNUTLS=y.
While at it, this commit also switches to a stable glibc Bootlin
external toolchain, to follow the new guidelines from [3].
Finally, this commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y and the
corresponding hash files. The .checkpackageignore is also updated to
reflect that change.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11026771001
[1] https://gitlab.com/buildroot.org/buildroot/-/commit/dc0f7215c604e845009e03784a221332867bf35a
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f07788079f515ca4a681c5f595bdad19cfbd7b1d
[3] https://elinux.org/Buildroot:DeveloperDaysELCE2024#Rules_for_defconfigs
Cc: Michel Stempin <michel.stempin@wanadoo.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
- Display active Buildroot versions as a table, similarly to kernel.org
- Add latest release date for all version
- Add expected End of Life dates for all versions
- Add link to the changelog
This makes the section much more compact, which makes it easier for
users to compare the versions and know what to expect from them
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The following dependency:
depends on !BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1
was added by commit d63e207eb8, which
bumped python3 from 3.12.9 to 3.13.2.
The commit message doesn't state it, but this dependency was introduced
because uClibc without time64 support (i.e. with kernel headers < 5.1)
causes a runtime assertion in Python [1]:
OverflowError: timestamp too large to convert to C PyTime_t
The problem is that this dependency has not been propagated to reverse
dependencies, causing this kind of kconfig warnings:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON3
Depends on [n]: BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n] && (!BR2_TOOLCHAIN_USES_UCLIBC [=y] || BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1 [=n])
Selected by [y]:
- BR2_PACKAGE_AVOCADO [=y] && BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
- BR2_PACKAGE_LIBSIGROKDECODE [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && BR2_USE_MMU [=y] && !BR2_STATIC_LIBS [=n]
- BR2_PACKAGE_OPKG_UTILS [=y] && BR2_PACKAGE_BUSYBOX [=y] && BR2_USE_MMU [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
However, propagating this dependency to all reverse dependencies of
python3 would be pretty annoying, especially as the dependency is kind
of "clunky". A configuration with uClibc and kernel headers < 5.1 is
such a corner case that it does not merit such complexity.
A later commit will check for this corner case at build time (while
allowing it in the .config). For now, already drop the dependency in
Config.in.
Cc: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
[1] https://gitlab.com/buildroot.org/buildroot/-/issues/95#note_2348479811
Since glibc 2.28, <sys/sysmacros.h> is no longer implicitly included
by <sys/types.h>, which means major() is only defined if you include
<sys/sysmacros.h>.
This wasn't really visible for a while in loadable plugins built by
lirc-tools as they could happily be built with undefined
symbols... except they would fail to load at runtime.
But then GCC 14.x brought more strict checking of having the function
prototype around, which now detects this issue at build time.
So the actual issue has been around since we switched to glibc 2.28,
but it only started failing to build since gcc 14.x. The first failure
is on August 2024, so this patch should be backported to our stable
branches.
The fix is backport from an upstream commit, post 0.10.2.
Fixes:
https://autobuild.buildroot.net/results/2f64accd430d9467add3f1195f3f59eff8e99a4d/
Minimal reproducer:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_STABLE=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_LIRC_TOOLS=y
# BR2_TARGET_ROOTFS_TAR is not set
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the manual doesn't mention the checkpackageignore file at
all, leaving the user under the assumption that running "make
check-package" and running utils/check-package directly on the package
they have touched would be equivalent, when the former evaluates the
checkpackageignore file while the latter does not. This could cause them
to forget to remove stale entries from that file.
Point out this difference in behavior.
Signed-off-by: Florian Larysch <fl@n621.de>
[Arnout: add that stale lines should be removed from
.checkpackageignore]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since the bump of libftdi1 to version v1.5-48-g22b4667a8 in commit
d8173e084e, the libftdi1.pc file is
installed in $(STAGING_DIR)/pkgconfig/libftdi1.pc instead of
$(STAGING_DIR)/lib/pkgconfig/libftdi1.pc, making it "invisible" to
pkg-config. This is turn causes flashrom to not find libftdi1 and
failing to build when libftdi1 is needed.
This issue is cause by CMAKE_INSTALL_LIBDIR being empty in libftdi1's
CMakeLists.txt, which in turn is due to include(GNUInstallDirs) being
missing. This has been fixed upstream a few commits later, so rather
than backporting a patch, let's just update to the commit containing
the fix, 5e67403c4fb5536a2effe2e91181dd73a2cff91b. The list of changes
upstream is:
5e67403c4fb5536a2effe2e91181dd73a2cff91b cmake: fix building static lib on windows/msvc
2e714eec137f86ca1950457d8226d8cb9b71c495 msvc: quiet uninteresting warnings
d96dbea887373f26755e9873b4ab020f922b7c3b fix unit var warning if ftdi_read_eeprom_location returned error, data would not be initialized
d31e3d5697eacbe87cd310b5bce615f3d8426cc0 cmake: fix elseif statement
c2b7c25e1272222c1719daea5761093fbc9c3010 msvc: fix shadowed variable warning
c4962c38a1ab470fbdc835c231567bd582eb5a5a msvc: fix warnings by using all enum values in case statements
2a992306c0acf938b29fa0cd5fbc160e24424209 Add SHAREDLIBS option
18499a2fa496c20e5e35590bb89eb701fa9fdfea Ignore VSCode temp folder
7676fb59ecd9fac9e5ea39439905c923ee7ee8c9 python/CMakeLists.txt: rework policy CMP0078
cfaec73e0a5ad9d05d62f1f5c393ab1c59ba771b C++ wrapper: get rid of the Boost dependency
12a8de0daba0816227c7010fc1b84d0abf70a500 .editorconfig: fix insert_final_newline option
3d7293651483130af9e8c5fe685d28b226baa99b Ignore clangd specific files
72e0e1e40126a2a9498fb249ca26a727bd670139 examples/async.c: remove unused includes
bfcdea286df81660b980a3bc91902b5970ff6347 examples/async.c: fix sometimes-uninitialized warning
(Yes the commit containing the fix is titled "cmake: fix building
static lib on windows/msvc", but because it adds
include(GNUInstallDirs), it also fixes our problem).
Fixes:
https://autobuild.buildroot.net/results/3600a9b7f323b4610ac67feb7171c0e10b6383d7/
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This defconfig no longer builds:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11012272989
It has been broken for at least 2 months, and it has no maintainer in
the DEVELOPERS file. We're adding Bartosz Bilas who has been the last
person doing updates to this defconfig.
Unless some fixes are provided, this defconfig will be dropped from
Buildroot.
Cc: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
# Board Revision is P307, same nvram file can be used for P304, P305, P306 and P307 as the tssi pa params used are same
#Please force the automatic RX PER data to the respective board directory if not using P307 board, for e.g. for P305 boards force the data into the following directory /projects/BCM43362/a1_labdata/boardtests/results/sdg_rev0305
To boot with Buildroot, insert this SD card on the board, make sure
the SD jumper is present and the U-Boot jumper is not.
The bootloader comes pre-flashed on the board on an SPI flash. Since
updating the bootloader is risky and not trivial, it is not included
in the Buildroot defconfig. Refer to
https://docs.embeddedts.com/TS-7680#U-Boot for details on
which U-Boot config to use and how to flash it.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Arnout Vandecappelle