See the release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352411&projectId=10510
Also update the download site to https
This fixes the following vulnerability:
- CVE-2024-23807:
The Apache Xerces C++ XML parser on versions 3.0.0 before 3.2.5
contains a use-after-free error triggered during the scanning of
external DTDs. Users are recommended to upgrade to version 3.2.5
which fixes the issue, or mitigate the issue by disabling DTD
processing. This can be accomplished via the DOM using a standard
parser feature, or via SAX using the XERCES_DISABLE_DTD environment
variable. This issue has been disclosed before as CVE-2018-1311, but
unfortunately that advisory incorrectly stated the issue would be
fixed in version 3.2.3 or 3.2.4.
https://www.cve.org/CVERecord?id=CVE-2024-23807
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 246f2eca20)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When building in parallel with per-package directories
(BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:
2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
Remove the spurious string between the timestamp and the ">>>" marker to
fix this.
We need some extra care to preserve the preceding "term bold" special
characters sequence.
We also prevent grep and sed to buffer their output too much. This leads to
more frequent output even when we might not be connected to a terminal; for
example: when brmake's output is piped to another program or when running
in CI.
Reviewed-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c9dca7f4c3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the many release notes: https://github.com/libvips/libvips/releases
Along that version bump:
- Change source code archive compression from .gz to .xz as this the
new upstream delivery format
- Switch from autotools to meson build system (see upstream commit
538aa2a841)
- Update the LICENSE file (see upstream commit
057703938e)
This fixes the following vulnerabilities:
- CVE-2025-29769:
libvips is a demand-driven, horizontally threaded image processing
library. The heifsave operation could incorrectly determine the
presence of an alpha channel in an input when it was not possible to
determine the colour interpretation, known internally within libvips
as "multiband". There aren't many ways to create a "multiband" input,
but it is possible with a well-crafted TIFF image. If a "multiband"
TIFF input image had 4 channels and HEIF-based output was requested,
this led to libvips creating a 3 channel HEIF image without an alpha
channel but then attempting to write 4 channels of data. This caused a
heap buffer overflow, which could crash the process. This
vulnerability is fixed in 8.16.1.
https://www.cve.org/CVERecord?id=CVE-2025-29769
- CVE-2025-59933:
libvips is a demand-driven, horizontally threaded image processing
library. For versions 8.17.1 and below, when libvips is compiled with
support for PDF input via poppler, the pdfload operation is affected
by a buffer read overflow when parsing the header of a crafted PDF
with a page that defines a width but not a height. Those using libvips
compiled without support for PDF input are unaffected as well as
thosewith support for PDF input via PDFium. This issue is fixed in
version 8.17.2. A workaround for those affected is to block the
VipsForeignLoadPdf operation via vips_operation_block_set, which is
available in most language bindings, or to set VIPS_BLOCK_UNTRUSTED
environment variable at runtime, which will block all untrusted
loaders including PDF input via poppler.
https://www.cve.org/CVERecord?id=CVE-2025-59933
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: update _LICENSE_FILES to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 72c7d99e22)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The patch bumps the Linux kernel to version 6.12.53
- stm32mp135f_dk_defconfig
- stm32mp157a_dk1_defconfig
- stm32mp157c_dk2_defconfig
Tested on STM32MP157C-DK2 Discovery Board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4552ed40bc)
[thomas: Only kernel bump]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The patch bumps the Linux kernel to version 6.1.155. The size of
xipImage has increased by only 1126 bytes (1673444 bytes compared to
1672318 in version 6.1.143).
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 675bb8337d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The patch bumps the Linux kernel to version 6.1.143. The size of xipImage
has increased by only 514 bytes (1672318 bytes compared to 1671804 in
version 6.1.133).
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 0c9a4b7995)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When mjpg-streamer is built with gcc >= 14 using libjpeg (rather than
jpeg-turbo), and with SDL is enabled (to enable the output_viewer),
the compilation can fail with error:
output_viewer.c:125:32: error: assignment to ‘boolean (*)(struct jpeg_decompress_struct *)’ from incompatible pointer type ‘int (*)(struct jpeg_decompress_struct *)’ [-Wincompatible-pointer-types]
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_LIBJPEG=y
BR2_PACKAGE_MJPG_STREAMER=y
BR2_PACKAGE_SDL=y
EOF
make olddefconfig
make mjpg-streamer
This commit adds a patch to fix this issue.
Fixes:
https://autobuild.buildroot.net/results/3a5/3a5674e4e7bb3f2894575191af24598e2a696912/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: add commands to reproduce the issue]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit af4eef1e0f)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Buildroot commit 553c55e9bd added the
qt6multimedia package including an option to build examples which
contains a dependency to qt6svg without selecting the package in
Config.in.
Fixes:
https://autobuild.buildroot.org/results/c94670cf255a1a6975e99d7b22a159f7fdc6f850/
Makefile:578: *** qt6svg is in the dependency chain of qt6multimedia
that has added it to its _DEPENDENCIES variable without selecting it
or depending on it from Config.in. Stop.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f37c48faf6)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Add an upstream patch to fix a build issue related to uint64_t:
utils.c: In function ‘get_uint64’:
utils.c:118:18: error: passing argument 1 of ‘str_toul’ from incompatible pointer type [-Wincompatible-pointer-types]
118 | str_toul(&defval, p, NULL, 16);
| ^~~~~~~
| |
| uint64_t * {aka long long unsigned int *}
In file included from utils.c:48:
utils.h:412:29: note: expected ‘long unsigned int *’ but argument is of type ‘uint64_t *’ {aka ‘long long unsigned int *’}
Fixes:
https://autobuild.buildroot.org/results/51af1d7bf71061f22d49213951a5f6a9565710c3/
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c8923662cc)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The patch bumps the Linux kernel to version 6.12.34-ti-arm32-r12
Tested on beaglebone black.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
(cherry picked from commit 98a3491d1c)
[thomas: only linux bump]
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Release notes: https://www.python.org/downloads/release/python-3138/
Fixes the following security issues:
gh-139400: xml.parsers.expat: Make sure that parent Expat parsers are only
garbage-collected once they are no longer referenced by subparsers created
by ExternalEntityParserCreate(). Patch by Sebastian Pipping.
gh-139283: sqlite3: correctly handle maximum number of rows to fetch in
Cursor.fetchmany and reject negative values for Cursor.arraysize. Patch by
Bénédikt Tran.
gh-135661: Fix CDATA section parsing in html.parser.HTMLParser according to
the HTML5 standard
https://docs.python.org/release/3.13.8/whatsnew/changelog.html#security
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Peter: Mark as security bump]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit d16c812b7e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the release notes:
- https://github.com/owasp-modsecurity/ModSecurity/releases/tag/v2.9.11
- https://github.com/owasp-modsecurity/ModSecurity/releases/tag/v2.9.12
This fixes the following vulnerabilities:
- CVE-2025-52891:
ModSecurity is an open source, cross platform web application firewall
(WAF) engine for Apache, IIS and Nginx. In versions 2.9.8 to before
2.9.11, an empty XML tag can cause a segmentation fault. If
SecParseXmlIntoArgs is set to On or OnlyArgs, and the request type is
application/xml, and at least one XML tag is empty (eg <foo></foo>),
then a segmentation fault occurs. This issue has been patched in
version 2.9.11. A workaround involves setting SecParseXmlIntoArgs to
Off.
https://www.cve.org/CVERecord?id=CVE-2025-52891
- CVE-2025-54571:
ModSecurity is an open source, cross platform web application firewall
(WAF) engine for Apache, IIS and Nginx. In versions 2.9.11 and below,
an attacker can override the HTTP response’s Content-Type, which could
lead to several issues depending on the HTTP scenario. For example, we
have demonstrated the potential for XSS and arbitrary script source
code disclosure in the latest version of mod_security2. This issue is
fixed in version 2.9.12.
https://www.cve.org/CVERecord?id=CVE-2025-54571
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 684462bbe8)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
See the release notes:
https://github.com/redis/redis/blob/8.0.4/00-RELEASENOTES
This fixes the following vulnerabilities (in the Lua scripting engine):
- CVE-2025-46817:
Redis is an open source, in-memory database that persists on disk.
Versions 8.2.1 and below allow an authenticated user to use a
specially crafted Lua script to cause an integer overflow and
potentially lead to remote code execution The problem exists in all
versions of Redis with Lua scripting. This issue is fixed in version
8.2.2.
https://www.cve.org/CVERecord?id=CVE-2025-46817
- CVE-2025-46818:
Redis is an open source, in-memory database that persists on disk.
Versions 8.2.1 and below allow an authenticated user to use a
specially crafted Lua script to manipulate different LUA objects and
potentially run their own code in the context of another user. The
problem exists in all versions of Redis with LUA scripting. This issue
is fixed in version 8.2.2. A workaround to mitigate the problem
without patching the redis-server executable is to prevent users from
executing LUA scripts. This can be done using ACL to block a script by
restricting both the EVAL and FUNCTION command families.
https://www.cve.org/CVERecord?id=CVE-2025-46818
- CVE-2025-46819:
Redis is an open source, in-memory database that persists on disk.
Versions 8.2.1 and below allow an authenticated user to use a
specially crafted LUA script to read out-of-bound data or crash the
server and subsequent denial of service. The problem exists in all
versions of Redis with Lua scripting. This issue is fixed in version
8.2.2. To workaround this issue without patching the redis-server
executable is to prevent users from executing Lua scripts. This can be
done using ACL to block a script by restricting both the EVAL and
FUNCTION command families.
https://www.cve.org/CVERecord?id=CVE-2025-46819
- CVE-2025-49844:
Redis is an open source, in-memory database that persists on disk.
Versions 8.2.1 and below allow an authenticated user to use a
specially crafted Lua script to manipulate the garbage collector,
trigger a use-after-free and potentially lead to remote code
execution. The problem exists in all versions of Redis with Lua
scripting. This issue is fixed in version 8.2.2. To workaround this
issue without patching the redis-server executable is to prevent users
from executing Lua scripts. This can be done using ACL to restrict
EVAL and EVALSHA commands.
https://www.cve.org/CVERecord?id=CVE-2025-49844
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since its inception in 9646e80fca (micropython: new package), the
ppc-specific CFLAGS are simply assigned, and since 9fd9f4e675
(package/micropython: define MICROPY_NLR_SETJMP for xtensa), the same
goes for the xtensa CFLAGS.
Although they are mutually exclusive (different archs) and that there is
no prior assignment, the customs are to use append assignment in
conditional blocks, to avoid accidentally overwriting a valure set
previously.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit be4fb117bc)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Before commit 50bc5aa17b (package/micropython: fix segfault at exit()
with gcc >= 14), only architecture-specific CFLAGS were passed, and only
one per arch. But 50bc5aa17b introduced a non-arch CFLAGS, for gcc
versions, so when the build happens for an architecture for which there
is a CFLAGS, and when gcc is 14 or newer, there are two CFLAGS added,
causing build failures:
[...] /usr/bin/make [...] CFLAGS_EXTRA=-DMICROPY_GCREGS_SETJMP=1 -DMICROPY_NLR_SETJMP=1 [...]
/usr/bin/make: invalid option -- 'D'
/usr/bin/make: invalid option -- 'M'
Usage: make [options] [target] ...
The fix is simple enough: just quote the CFLAGS.
Fixes: https://autobuild.buildroot.org/results/b18/b18d6fa9938c1267a771fdbcd8b4c3df812cd6b9/
Fixes: 50bc5aa17b
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Chris Packham <judge.packham@gmail.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit ab906018c9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The update makes some warnings about unknown classes and permissions
during boot with current kernels go away.
Upstream changelogs [1, 2] list as "notable changes":
* Updates to support screen 5.0.
* Add labeling for bcachefs.
* Various systemd updates and fixes.
* Several updates and fixes for systemd
* Add new permissions and policy capabilities
* Drop reiserfs support (it was removed in kernel 6.13)
Plus a number of new modules.
[1] https://github.com/SELinuxProject/refpolicy/releases/tag/RELEASE_2_20250618
[2] https://github.com/SELinuxProject/refpolicy/releases/tag/RELEASE_2_20250923
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Julien: keep a new line in hash file between sources and license]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a843be3451)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The previous URL [1] currently redirects to [2], which as of this
commit is about two months old and contains a readme that just says
"PoC by Callgh0st". When the package was added with commit [3]
the help text URL matched REFPOLICY_SITE, so presumably the help was
forgotten when the site URL was updated in [4], and there has been
some kind of hostile takeover of the former upstream repository since.
[1] https://github.com/TresysTechnology/refpolicy
[2] https://github.com/Exact-Realty/refpolicy
[3] bb442abdf1
[4] cfa018d9f3
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Julien: add commit ID which forgot to update the package homepage]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b9d3a0418b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
$(PREFIX)/lib/python$(PYTHON3_VERSION_MAJOR) is for the standard
library, additional modules like this should go to site-packages.
This patch changes only the host package because Python bindings are
disabled for the target package.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8d79f712ce)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
/usr/lib/python$(PYTHON3_VERSION_MAJOR) is for the standard library,
additional modules like this should go to site-packages.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 43b8f57afd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Drop upstream patch.
Main change in this release is cmake 4 build fix.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7176f6b287)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
