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>
The SBSA Reference Platform was updated to neoverse-n2 (armv9.0a)
in Qemu v9.1 [1].
The Armv9-A and Neoverse N2 core support was added in Buildroot
commit [2].
Since the test_edk2 uses the Qemu sbsa-ref machine, this commit
aligns it to use the neoverse-n2 cpu.
[1] b1d592e7b0
[2] 9845bd4541
Signed-off-by: Julien Olivain <ju.o@free.fr>
The SBSA Reference Platform was updated to neoverse-n2 (armv9.0a)
in Qemu v9.1 [1].
The Armv9-A and Neoverse N2 core support was added in Buildroot
commit [2].
Since the test_fwts uses the Qemu sbsa-ref machine, this commit
aligns it to use the neoverse-n2 cpu.
[1] b1d592e7b0
[2] 9845bd4541
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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
- bb7d62bd0a
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes the following vulnerability:
- CVE-2023-51257:
An invalid memory write issue in Jasper-Software Jasper v.4.1.1 and
before allows a local attacker to execute arbitrary code.
For more information see:
- https://nvd.nist.gov//vuln/detail/CVE-2023-51257
- aeef5293c9
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
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>
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>
We dropped support for python2 a while back in [1], as such we
can remove the python six module which was only needed for
backwards comaptibility with python2.
[1] 2743ce00ca
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[Julien: add commit ref removing python2 support]
Signed-off-by: Julien Olivain <ju.o@free.fr>
