eeb65cf0f6 manually backported upstream
util-linux security fix (util-linux: 5e390467b26a3cf3fecc04e1a0d482dff3162fc4)
but didn't account for ul_canonicalize_path being named just canonicalize_path
in 2.40.x. Use the upstream backported patch from the 2.40.x maintenance
branch instead.
Can be reproduced with the following defconfig:
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_PACKAGE_UTIL_LINUX_LOSETUP=y
Fixes: eeb65cf0f6
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[thomas: added defconfig]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://download.gnome.org/sources/libxml2/2.15/libxml2-2.15.3.news
- parser: Pass userData to SAX text callbacks in xmlParseReference (type-confusion)
- entities: copy children in xmlCopyEntity
- c14n: Fix Type confusion in xmlC14NProcessAttrsAxis
- python: Do not decref string after adding to the list (double-free / use-after-free)
- c14n: Reuse tmp_str, xmlStrcat reallocates *cur (double-free)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c1a34838b9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Building this defconfig
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_NEON=y
BR2_PACKAGE_NEON_ZLIB=y
does not build libneon with zlib support, quoting configure log:
configure: zlib not enabled
although the configure parameter
--with-zlib=/home/bernd/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot
was used.
The reason is the addition of "=$(STAGING_DIR)" to --with-zlib which was
added to buildroot in 2008 with commit
cc6562ff83.
The upstream code, which expects only "yes", all other values lead to
the else-condition, is unchanged since 2004:
https://github.com/notroj/neon/blame/0.37.1/macros/neon.m4#L478
so a backport of this patch to LTS branches should be considered.
With this patch the configure log shows:
checking for zlib.h... yes
checking for inflate in -lz... yes
configure: zlib support enabled, using -lz
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5e917c3a81)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
- sources are now hosted on Github
- ficl have its own LICENSE file
- remove one upstreamed patch
- support only static lib
- requires C11
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e7dcf9e5af)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit 1c11f9020a removed the patch
changing configure.ac with the bump to 6.10, so it is no longer
needed.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 9fd8a1cf49)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the release notes:
https://docs.djangoproject.com/en/5.2/releases/5.2.13/
In addition, update the pypi url to a stable one, which shouldn't change
in each and every release (similar to the url change in commit
60ce218196)
Finally, one hash file has changed because of upstream commit
0ee44c674c
Django 5.2.13 fixes one security issue with severity "moderate",
and four security issues with severity "low":
- CVE-2026-3902:
An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and
4.2 before 4.2.30. `ASGIRequest` allows a remote attacker to spoof
headers by exploiting an ambiguous mapping of two header variants
(with hyphens or with underscores) to a single version with
underscores. Earlier, unsupported Django series (such as 5.0.x, 4.1.x,
and 3.2.x) were not evaluated and may also be affected. Django would
like to thank Tarek Nakkouch for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-3902
- CVE-2026-4277:
An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and
4.2 before 4.2.30. Add permissions on inline model instances were not
validated on submission of forged `POST` data in
`GenericInlineModelAdmin`. Earlier, unsupported Django series (such as
5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank N05ec@LZU-DSLab for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-4277
- CVE-2026-4292:
An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and
4.2 before 4.2.30. Admin changelist forms using
`ModelAdmin.list_editable` incorrectly allowed new instances to be
created via forged `POST` data. Earlier, unsupported Django series
(such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be
affected. Django would like to thank Cantina for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-4292
- CVE-2026-33033:
An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and
4.2 before 4.2.30. `MultiPartParser` allows remote attackers to
degrade performance by submitting multipart uploads with `Content-
Transfer-Encoding: base64` including excessive whitespace. Earlier,
unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not
evaluated and may also be affected. Django would like to thank
Seokchan Yoon for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-33033
- CVE-2026-33034:
An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and
4.2 before 4.2.30. ASGI requests with a missing or understated
`Content-Length` header could bypass the
`DATA_UPLOAD_MAX_MEMORY_SIZE` limit when reading `HttpRequest.body`,
allowing remote attackers to load an unbounded request body into
memory. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and
3.2.x) were not evaluated and may also be affected. Django would like
to thank Superior for reporting this issue.
https://www.cve.org/CVERecord?id=CVE-2026-33034
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the release notes:
https://github.com/OpenVPN/openvpn/blob/v2.6.20/Changes.rst
This fixes 2 security issues:
- CVE-2026-40215:
race condition in TLS handshake that could lead to leaking of packet
data from a previous handshake under specific circumstances
- CVE-2026-35058:
server ASSERT() on receiving a suitably malformed packet with a valid
tls-crypt-v2 key
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
(cherry picked from commit 1a4a04fe29)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
For change log, see:
https://logging.apache.org/log4cxx/1.7.0/changelog.html
This fixes the following vulnerability:
- CVE-2026-40023:
Apache Log4cxx's XMLLayout
https://logging.apache.org/log4cxx/1.7.0/classlog4cxx_1_1xml_1_1XMLLayout.html,
in versions before 1.7.0, fails to sanitize characters forbidden
by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets
in log messages, NDC, and MDC property keys and values, producing
invalid XML output. Conforming XML parsers must reject such
documents with a fatal error, which may cause downstream log
processing systems to drop or fail to index affected records.
An attacker who can influence logged data can exploit this
to suppress individual log records, impairing audit trails and
detection of malicious activity. Users are advised to upgrade to
Apache Log4cxx 1.7.0, which fixes this issue.
https://www.cve.org/CVERecord?id=CVE-2026-40023
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: add link to change log in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1d5c6d18da)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
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>
(cherry picked from commit 70a16560b2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
- CVE-2026-27456: mount(8) TOCTOU symlink attack via loop device. The SUID
mount follows symlinks when resolving loop backing file paths. On
systems where non-root users are permitted to mount loop devices (via
'user' option in fstab), this allows access to arbitrary files.
For more information, see:
- https://nvd.nist.gov/vuln/detail/CVE-2026-27456
- 5e390467b2
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
(cherry picked from commit cd52acda14)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The host-mkpasswd package needs the <crypt.h> header file installed
on the host. This file was initially provided by the libc headers,
as part of its libcrypt implementation. libcrypt was removed in
glibc 2.39. Most Linux distributions continued to ship a libcrypt
replacement such as libxcrypt in their default installation.
Some mainstream Linux distribution (such as Debian testing) are
now starting to remove this libcrypt and <crypt.h> header from their
default image (of development files).
In that case, host-mkpasswd is failing to build with the error:
/buildroot/output/build/host-mkpasswd/mkpasswd.c:54:10: fatal error: crypt.h: No such file or directory
The issue can be reproduced by adapting the Buildroot Docker file,
by setting "FROM debian:testing-20260316" in [1] and removing
the build of tar.
Note: debian 13 (for example Docker tag trixie-20260316) still
includes the libcrypt-dev package by default, which provides crypt.h.
In Buildroot, there is already the host-heimdal and host-systemd
packages requiring host-libxcrypt. Also, the host-libxcrypt is a
small standalone package. For those reasons, instead of adding
the Buildroot prerequisite on the user host to provide a libcrypt
implementation, this commit simply add the package dependency to
host-libxcrypt, to make sure it will work in all situations.
[1] https://gitlab.com/buildroot.org/buildroot/-/blob/2026.02/support/docker/Dockerfile#L11
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
(cherry picked from commit cf26c77280)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://github.com/libexif/libexif/blob/v0.6.26/NEWS
* Security issues fixed:
* CVE-2026-40386: An unsigned integer underflow in Fuji and Olympus
makernote handling
* CVE-2026-40385: An unsigned integer overflow on 32bit systems in
Nikon makernote handling
* CVE-2026-32775: A buffer overwrite via integer underflow in makernote
handling
Switched to xz tarball and tarball hash provided by upstream.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3f9bcf42c3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This fixes the following vulnerability:
- CVE-2026-25075:
strongSwan versions 4.5.0 prior to 6.0.5 contain an integer underflow
vulnerability in the EAP-TTLS AVP parser that allows unauthenticated
remote attackers to cause a denial of service by sending crafted AVP
data with invalid length fields during IKEv2 authentication. Attackers
can exploit the failure to validate AVP length fields before
subtraction to trigger excessive memory allocation or NULL pointer
dereference, crashing the charon IKE daemon.
https://www.cve.org/CVERecord?id=CVE-2026-25075
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
(cherry picked from commit cc7c20d817)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Using this defconfig
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_PACKAGE_STRONGSWAN=y
BR2_PACKAGE_STRONGSWAN_WOLFSSL=y
applied after 'git reset 10a70b1af6 --hard'
replicates the build error
http://autobuild.buildroot.net/results/278b3f74c48c858ae368d59069752adb69c05246
which was fixed in 2024 by
89d512729c
Note: The git tree was reset to the commit right before the fix.
Instead of using the fix mentioned above the build error is also fixed
when the buildroot commit 6c18375434 is
cherry-picked onto 10a70b1af6.
This means the build error mentioned above is really fixed by enabling
BR2_PACKAGE_WOLFSSL_ALL. Therefore we can remove the content of commit
89d512729c.
This commit also prevents a build error in strongswan
wolfssl_rsa_private_key.c: In function 'create_empty':
wolfssl_rsa_private_key.c:450:18: error: 'RsaKey' has no member named 'rng'
450 | this->rsa.rng = &this->rng;
caused by the upcoming bump of wolfSSL from 5.7.2 to 5.9.1 due to
upstream commit
cd88a8ae88
which was first included in wolfSSL 5.9.0.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5d6378db9d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
