This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_STABLE=y in the
defconfig, bumps kernel to 6.16.7, and adds custom hash files and
removes the exception entry in .checkpackageignore.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[Julien:
- mention kernel bump in commit title
- move BR2_DOWNLOAD_FORCE_CHECK_HASHES=y down in defconfig
- remove linux-headers hash file
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Increase again the partition size to accommodate latest kernel.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV6_EABIHF_GLIBC_STABLE=y in the
defconfig, bumps kernel to 6.16.7, and adds custom hash files and
removes the exception entry in .checkpackageignore.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[Julien:
- mention kernel bump in commit title
- move BR2_DOWNLOAD_FORCE_CHECK_HASHES=y down in defconfig
- remove linux-headers hash file
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
This fixes building sysprof when elfutils is also selected (which is
a common setup). The debuginfod client support relies in elfutils
being built with the libdebuginfod option enabled; but Buildroot
unconditionally disables it in the elfutils package. See commit [1].
[1] 52c5c6050c
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Julien: add link to commit disabling debuginfod]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Many links pointing to buildroot.org are still prefixed with HTTP.
Update those to HTTPS.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y in the defconfig
and adds custom hash files. The exception entry in .checkpackageignore
is also removed.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
[Julien: change linux.hash comment to reuse hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
Update icu to 77.1.
The LICENSE file contains a lot of changes, so no diff
is presented.
Patch 0002-workaround-toolchain-bugs.patch is no longer required.
Reorder the other patches accordingly.
Update patch 0003-fix-static-linking-with-icu-uc.patch so that
it applies cleanly.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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] a016b693f7
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>
As reported on the mailing list [1] while investigating the
TestZfsUclibc Gitlab-CI failure, the python 3.13 interpreter itsef
segfault at runtime:
Fatal Python error: _PyThreadState_Attach: non-NULL old thread state
Python runtime state: preinitialized
Thread 0xSegmentation fault
This issue is related to the python 3.13 version bump [2] were several
internal changes were added [3] to support PEP 703 [4].
PEP 793 is about CPython’s global interpreter lock (“GIL”) removal
for multi-threads support that requires a working C11 "thread_local"
for thread-local storage [5].
The new uclibc-ng 1.0.55 release contains a fix for this issue [6].
This version is included in Buildroot commit [7].
Since the prebuilt Bootling aarch64 uclibc stable 2025.08-1 is based
on previous uClibc-ng release (1.0.54) we have to use the internal
toolchain backend to build a new uClibc-ng toolchain using uclibc-ng
1.0.55. Note: the toolchain config defined in this commit reflects
the options enabled in the Bootling aarch64 uclibc external
toolchains.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124859 (TestZfsUclibc)
[1] https://lore.kernel.org/buildroot/7a4d245d-1556-43c9-8997-6b1f791afbfe@gmail.com/ (TestZfsUclibc)
[2] d63e207eb8
[3] 6e97a9647a
[4] https://peps.python.org/pep-0703/
[5] https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Thread-Local.html
[6] 94c1297d52
[7] 5250bba8e5
Cc: José Luis Salvador Rufo <salvador.joseluis@gmail.com>
Tested-by: José Luis Salvador Rufo <salvador.joseluis@gmail.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Julien:
- add link to buildroot commit updating uclibc-ng to 1.0.55
- add a note in the commit log about the toolchain config
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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
- 6f2f85913c
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Update all qemu defconfigs to the latest Kernel LTS version.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
aespipe-v2.4i April 29 2025
- Added AES Crypto Extension opcodes for 64-bit arm64 on Linux.
- aes-armv8sca.S aes-armv8ce.S : add PAC/BTI branch protection
support. Patch from Emanuele Rocca <emanuele.rocca@arm.com>
aespipe-v2.4j September 2 2025
- Added configure script autodetection for 32-bit ARM -marm compile
flag. This option is needed with some compilers that default to
generating code in Thumb mode.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following vulnerability:
- CVE-2025-55763
Buffer Overflow in the URI parser of CivetWeb 1.14 through 1.16 (latest)
allows a remote attacker to achieve remote code execution via a crafted
HTTP request. This vulnerability is triggered during request processing
and may allow an attacker to corrupt heap memory, potentially leading to
denial of service or arbitrary code execution.
For more information, see:
- https://nvd.nist.gov//vuln/detail/CVE-2025-55763
- 76e222bcb7
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
