When using a specific git repo and version for at91bootstrap3,
BR2_TARGET_AT91BOOTSTRAP3_LICENSE_FILES defaults to "LICENSES/MIT.txt".
However the git version we use (namely v3.10.3) does not provide this
file. Actually, it does not provide a license file at all. This causes
‘make legal-info’ to fail with:
>>> at91bootstrap3 v3.10.3 Collecting legal info
sha256sum: /builds/buildroot.org/buildroot/output/build/at91bootstrap3-v3.10.3/LICENSES/MIT.txt: No such file or directory
ERROR: while checking hashes from boot/at91bootstrap3/at91bootstrap3.hash
ERROR: LICENSES/MIT.txt has wrong sha256 hash:
ERROR: expected: 5a3809b1c2ba13b7242572322951311c584419f1f8516f665d6c06f0668d78de
ERROR: got :
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
Let's be explicit that there is no license file to check.
Fixes:
- https://gitlab.com/buildroot.org/buildroot/-/jobs/12992815386
- https://gitlab.com/buildroot.org/buildroot/-/jobs/12992815390
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot commit [1] introduced two small typos, while doing the
updates to announce new releases.
The version 2025.02.10 release date is 2026-01-20 (and not 2022).
See the original announce [2].
The 2025.02.10 archive link in news.html has also a missing dot.
This commit fixes those typo in order to fix the website.
[1] 21dda0665e
[2] https://lore.kernel.org/buildroot/9b9654f8-6cdd-4108-b932-79509e455148@rnout.be/
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libxmslec1 build fails on some configurations with the following build
logs:
CC libxmlsec1_openssl_la-kw_des.lo
kw_des.c:75:8: error: unknown type name 'xmlSecKWDes3Klass'; did you mean 'xmlSecKWAesKlass'?
75 | static xmlSecKWDes3Klass xmlSecOpenSSLKWDes3ImplKlass = {
| ^~~~~~~~~~~~~~~~~
| xmlSecKWAesKlass
kw_des.c:77:5: error: initialization of 'int' from 'int (*)(struct _xmlSecTransform *, xmlSecByte *, size_t, size_t *)' {aka 'int (*)(struct _xmlSecTransform *, unsigned char *, long unsigned int, long unsigned int *)'} makes integer from pointer without a cast [-Wint-conversion]
77 | xmlSecOpenSSLKWDes3GenerateRandom, /* xmlSecKWDes3GenerateRandomMethod generateRandom; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:77:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:77:5: error: initializer element is not computable at load time
kw_des.c:77:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:78:5: error: excess elements in scalar initializer
78 | xmlSecOpenSSLKWDes3Sha1, /* xmlSecKWDes3Sha1Method sha1; */
| ^~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:78:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:79:5: error: excess elements in scalar initializer
79 | xmlSecOpenSSLKWDes3BlockEncrypt, /* xmlSecKWDes3BlockEncryptMethod encrypt; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kw_des.c:79:5: note: (near initialization for 'xmlSecOpenSSLKWDes3ImplKlass')
kw_des.c:80:5: error: excess elements in scalar initializer
80 | xmlSecOpenSSLKWDes3BlockDecrypt, /* xmlSecKWDes3BlockDecryptMethod decrypt; */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
This build failure is due to those struct definitions being set
conditionally in src/kw_aes_des.h behind a XMLSEC_NO_DES define, and
this define ending up being 1 on some builds. We could assume that the
makefiles in libxmlsec should just not try to build any DES related file
when XMLSEC_NO_DES is set to 1 (and so, in this specific case, not try
to build src/openssl/kw_des.c), but the autotools tooling in the project
is not the one setting XMLSEC_NO_DES: there is a mismatch between
detected features at configure time and build time.
- at build time, the tooling just checks if user has passed
`--enable-des=no`. If so, it sets XMLSEC_NO_DES, otherwise it assumes
that DES support is available.
- at build time, libxmlsec tries to build openssl backend. This backend
checks OpenSSL features, especially whether OPENSSL_NO_DES is set (and
if so, it enforces XMLSEC_NO_DES to 1 as well)
- This OPENSSL_NO_DES comes from libopenssl configuration headers
installed in sysroot. Its presence is driven by the `no-des` option
passed at libopenssl configure time
- This `no-des` flag is driven by buildroot option
BR2_PACKAGE_LIBOPENSSL_ENABLE_DES
There are multiple options to fix this package here:
1. fixing upstream package to make the features detection more robust (eg
check openssl headers at configure time to ensure that DES is
supported)
2. enforce XMLSEC_NO_DES if BR2_PACKAGE_LIBOPENSSL_ENABLE_DES is not set
3. systematically enforce XMLSEC_NO_DES=1
Now:
- 1 may take time, and would then need a temporary patch to live in
buildroot while the fix is accepted upstream and released
- 2 works only for libopenssl, what if libressl is used ?
- DES usage is discouraged anyway, as stated by configure logs:
[...]
checking for DES support... yes (use discouraged)
[...]
As the package has been introduced very recently, there's a very low
chance to break any user use case by completely disabling DES support.
Systematically disable DES support in libxmlsec1 to discourage usage and
fix build failure when the corresponding SSL library does not expose DES
support.
Fixes: https://autobuild.buildroot.org/results/3e15f03dc0211c622125ebb69ff7230ce900029a/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* bumps ATF to version 2.14.0
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit also updates
olimex_a20_olinuxino_lime_defconfig
olimex_a20_olinuxino_lime2_defconfig
to use this new rootfs_overlay_mali directory.
This is to differentiate for the upcoming patch for
a20_olinuxino_micro_defconfig
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: add extra info in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
* switches to extlinux
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien:
- change linux.hash comment to use hash from upstream
- add "_lime" in commit title
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version lf-6.12.49-2.2.0
* bumps U-Boot to version lf-6.12.49-2.2.0
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
* forces check hashes
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The patch:
* bumps Linux kernel to version 6.18.8
* bumps U-Boot to version 2026.01
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Julien: change linux.hash comment to use hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The `pocoo:jinja2` CPE introduced in commit [1] is not deprecated but is
no longer used. All the security issue on the Github Advisory reference
CVE with the `palletsprojects:jinja` CPE instead (see [2]).
This commit updates the CPE accordingly.
[1] 165f60a092 package/python-jinja2: add CPE variables
[2] https://github.com/pallets/jinja/security/advisories/GHSA-cpwx-vrp4-4pq7
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Optional udisks support is useful for mounting USB sticks via
pcmanfm.
gvfs meson.build has recognized this udisks2 option for quite
some time, since upstream commit [1] first included in version
1.35.2 (released on 2017-11-13).
[1] cdc33bf54f
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Julien: add comment in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
commit cf686670b9 introduced a patch that
was later included in a release which made the usage of libesmtp
configurable. Later the switch was moved to the main CMakeLists.mk [0].
while the patch introduced the build flag LOG4CXX_ENABLE_ESMTP the
change to the .mk file used LOG4CXX_ENABLE_LIBESMTP.
So correct this.
Fixes:
CMake Warning:
Manually-specified variables were not used by the project:
LOG4CXX_ENABLE_LIBESMTP
[0] https://github.com/apache/logging-log4cxx/blob/rel/v1.3.1/CMakeLists.txt#L93
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit backports an upstream patch fixing CVE-2024-10963. See:
https://github.com/linux-pam/linux-pam/issues/834https://github.com/linux-pam/linux-pam/pull/854
Fixes:
- CVE-2024-10963:
Pam: improper hostname interpretation in pam_access leads to access
control bypass
A flaw was found in pam_access, where certain rules in its
configuration file are mistakenly treated as hostnames. This
vulnerability allows attackers to trick the system by pretending
to be a trusted hostname, gaining unauthorized access. This issue
poses a risk for systems that rely on this feature to control who
can access certain services or terminals.
https://www.cve.org/CVERecord?id=CVE-2024-10963
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
[Julien:
- fix check-package errors
- add info in commit log
- rebase patch on v1.6.1 to avoid patch offsets
- add "CVE:" tag in patch
- add comment with patch name near _IGNORE_CVES in .mk
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit:
- updates the Kernel from LTS 6.6.30 to 6.12.70
- updates U-Boot from 2024.04 to 2026.01
- updates arm-trusted-firmware from v2.10 to v2.12 LTS
- switches to Bootlin external glibc stable toolchain
Note: Using the kernel 6.18.9, the SD card fail at boot:
mmc1: SDHCI controller on 4fb0000.mmc [4fb0000.mmc] using ADMA 64-bit
Waiting for root device /dev/mmcblk1p2...
mmc1: error -110 whilst initialising SD card
So let's use stable kernel 6.12.y for the time being.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Julien: update linux.hash comment to use upstream hash]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Please note that the fix for CVE-2024-52615 introduces CVE-2025-59529
which is not fixed yet (https://github.com/avahi/avahi/pull/808). You
can mitigate this vulnerability by setting the `enable-wide-area=no`
option.
Patch `0011-properly-randomize-query-id-of-DNS-packets.patch` modify
`configure.ac` and then `AVAHI_AUTORECONF` is set.
This commit fixes the following vulnerabilities:
- CVE-2021-3468:
A flaw was found in avahi in versions 0.6 up to 0.8. The event used to
signal the termination of the client connection on the avahi Unix
socket is not correctly handled in the client_work function, allowing
a local attacker to trigger an infinite loop. The highest threat from
this vulnerability is to the availability of the avahi service, which
becomes unresponsive after this flaw is triggered.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2021-3468
- 447affe299
- CVE-2023-38469:
A vulnerability was found in Avahi, where a reachable assertion exists
in avahi_dns_packet_append_record.
https://www.cve.org/CVERecord?id=CVE-2023-38469
- CVE-2023-38470:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_escape_label() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38470
- a337a1ba7d
- CVE-2023-38471:
A vulnerability was found in Avahi. A reachable assertion exists in
the dbus_set_host_name function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38471
- github.com/avahi/avahi/commit/894f085f402e023a98cbb6f5a3d117bd88d93b09
- CVE-2023-38472:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_rdata_parse() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38472
- b024ae5749
- CVE-2023-38473:
A vulnerability was found in Avahi. A reachable assertion exists in
the avahi_alternative_host_name() function.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2023-38473
- b448c9f771
- CVE-2024-52615:
A flaw was found in Avahi-daemon, which relies on fixed source ports
for wide-area DNS queries. This issue simplifies attacks where
malicious DNS responses are injected.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2024-52615
- 4e2e1ea090
- https://github.com/avahi/avahi/issues/810 (introduce regression CVE-2025-59529)
- CVE-2024-52616:
A flaw was found in the Avahi-daemon, where it initializes DNS
transaction IDs randomly only once at startup, incrementing them
sequentially after that. This predictable behavior facilitates DNS
spoofing attacks, allowing attackers to guess transaction IDs.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2024-52616
- f8710bdc8b
- CVE-2025-68276:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an
unprivileged local users can crash avahi-daemon (with wide-area
disabled) by creating record browsers with the
AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by
either calling the RecordBrowserNew method directly or creating
hostname/address/service resolvers/browsers that create those browsers
internally themselves.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68276
- 2d48e42d44
- CVE-2025-68468:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier,
avahi-daemon can be crashed by sending unsolicited announcements
containing CNAME resource records pointing it to resource records with
short TTLs. As soon as they expire avahi-daemon crashes.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68468
- f66be13d7f
- CVE-2025-68471:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier,
avahi-daemon can be crashed by sending 2 unsolicited announcements
with CNAME resource records 2 seconds apart.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-68471
- 9c6eb53bf2
- CVE-2026-24401:
Avahi is a system which facilitates service discovery on a local
network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and
below, avahi-daemon can be crashed via a segmentation fault by sending
an unsolicited mDNS response containing a recursive CNAME record,
where the alias and canonical name point to the same domain (e.g.,
"h.local" as a CNAME for "h.local"). This causes unbounded recursion
in the lookup_handle_cname function, leading to stack exhaustion. The
vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST
is set explicitly, which includes record browsers created by resolvers
used by nss-mdns. This issue is patched in commit
78eab31128479f06e30beb8c1cbf99dd921e2524.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24401
- 78eab31128
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The github repository lathiat/avahi now redirect to avahi/avahi.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Introduce the openscap package. openscap is a command line tool allowing
to scan a system configuration to perform security compliance checks.
The tool consumes XCCDF and OVAL files to perform system evaluation
against a list of policies.
The package provides both a target and a host build configuration, as it
is needed on both sides:
- it is needed on the host to allow building the security policy files
to be embedded on the target
- it is needed on the target to actually parse and evaluate those
security policy files.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Thomas:
- Drop dependency on openssl, apparently not needed
- Depend on gcrypt if !nss, as either can be used
- Add missing dependency on libxslt]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libcurl host build support has initially been added with 736e0fc5d6
("libcurl: add host variant") while adding support for host-cargo build,
and reverted with 69e84008ab ("Revert "libcurl: add host variant"")
when standalone cargo build has been removed.
In order to bring in an upcoming commit a new host package that
depends on libcurl, re-enable host-libcurl build support.
This reverts commit w9e84008abf87eaeeb3f2d53c880cf33492a3bf8, with the
exception of the post-patch hook which is no longer needed.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 7eeb574f0e introduced the
libxmlsec1 making libxslt a mandatory dependency, which it isn't.
This commit therefore make libxslt an optional dependency of the
target libxmlsec1 package, and drops the dependency entirely for the
host package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes CVE-2025-14550:
There was a potential DoS vector for users of the
``asgiref.wsgi.WsgiToAsgi`` adapter. Malicious requests, including an
unreasonably large number of values for the same header, could lead to
resource exhaustion when building the WSGI environment.
Changelog: https://github.com/django/asgiref/blob/3.11.1/CHANGELOG.txt
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The CPIO filesystem generated by the test_firewalld test is too
large, and doesn't fit as an initramfs in the 256MB of RAM available
in the versatilepb machine. This causes a "Initramfs unpacking failed:
write error" when booting, and many files being missing from the root
filesystem, ultimately causing the test to fail.
The test_firewalld test initially started to fail following a systemd
update [1][3]:
[BRTEST# systemctl is-active firewalld
failed
But really started to crash at boot following a python 3.14 update
[2][4]:
Run /init as init process
/init: exec: line 15: /sbin/init: not found
Also, update TestFirewalldSysVInit to use ext2 instead of cpio.
[1] 926e0504d0
[2] a0a6abc8b1
Fixes:
[3] https://gitlab.com/buildroot.org/buildroot/-/jobs/12944797059
[4] https://gitlab.com/buildroot.org/buildroot/-/jobs/11856840940
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
