Fixes the following security issues:
- CVE-2025-13473 (low): Username enumeration through timing difference in mod_wsgi authentication handler
- CVE-2025-14550 (moderate): Potential denial-of-service vulnerability via repeated headers when using ASGI
- CVE-2026-1207 (high): Potential SQL injection via raster lookups on PostGIS
- CVE-2026-1285 (moderate): Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods
- CVE-2026-1287 (high): Potential SQL injection in column aliases via control characters
- CVE-2026-1312 (high): Potential SQL injection via QuerySet.order_by and FilteredRelation
See the release notes here:
https://docs.djangoproject.com/en/dev/releases/6.0.2/
Also includes the bugfixes from version 6.0.1:
https://docs.djangoproject.com/en/dev/releases/6.0.1/
Signed-off-by: Manuel Diener <manuel.diener@othermo.de>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Introduce the libxmlsec1 library package. libxmlsec implements XML
security standards.
The library has only a few mandatory dependencies(libxml2 and libxslt
and a crypto library). It needs one of the following cryptographic
libraries: OpenSSL, NSS, or Gcrypt/GNUTLS. Default to openssl for now to
keep the package simple.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security vulnerabilities:
CVE-2026-1584: libgnutls: Fix NULL pointer dereference in PSK binder
verification
A TLS 1.3 resumption attempt with an invalid PSK binder value in ClientHello
could lead to a denial of service attack via crashing the server.
The updated code guards against the problematic dereference.
CVE-2025-14831: libgnutls: Fix name constraint processing performance issue
Verifying certificates with pathological amounts of name constraints
could lead to a denial of service attack via resource exhaustion.
Reworked processing algorithms exhibit better performance characteristics.
For more details, see the release notes:
https://lists.gnupg.org/pipermail/gnutls-help/2026-February/004914.html
Drop now upstreamed 0001-audit-crau-fix-compilation-with-gcc-11.patch:
f5666f8f1f
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following vulnerabilities:
CVE-2025-61732: cmd/cgo: remove user-content from doc strings in cgo ASTs
A discrepancy between how Go and C/C++ comments were parsed allowed for code
smuggling into the resulting cgo binary.
To prevent this behavior, the cgo compiler will no longer parse
user-provided doc comments.
CVE-2025-68121: crypto/tls: unexpected session resumption when using
Config.GetConfigForClient
Config.GetConfigForClient is documented to use the original Config's session
ticket keys unless explicitly overridden. This can cause unexpected
behavior if the returned Config modifies authentication parameters, like
ClientCAs: a connection initially established with the parent (or a sibling)
Config can be resumed, bypassing the modified authentication requirements.
If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on
the server) or InsecureSkipVerify is false (on the client), crypto/tls now
checks that the root of the previously-verified chain is still in
ClientCAs/RootCAs when resuming a connection.
Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar
issue related to session ticket keys being implicitly shared by
Config.Clone. Since this fix is broader, the Config.Clone behavior change
has been reverted.
Note that VerifyPeerCertificate still behaves as documented: it does not
apply to resumed connections. Applications that use
Config.GetConfigForClient or Config.Clone and do not wish to blindly resume
connections established with the original Config must use VerifyConnection
instead (or SetSessionTicketKeys or SessionTicketsDisabled).
For more details, see the announcement:
https://groups.google.com/g/golang-announce/c/K09ubi9FQFk
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Blake3 unconditionally enables C++ support, which unconditionally
requires C++20 when built with cmake >= 3.12, even when this is not
required.
Fixing this does not look trivial, and rather than botching the build,
just require C++20, available from gcc 8.x onward.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Use of threading requires a C++20 compiler, and the oneTBB
implementation. oneTBB is missing from Buildroot, but a system
one may be used if found.
Even if the default for threading is disabled, explicitly state so,
in case the default changes in the future.
Also disable examples, we don't and won't need them.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Ensure that the SHA_CRYPT option is enabled when the system configuration is
set to SHA256/512, as otherwise passwd complains when a password is changed:
passwd
...
Invalid ENCRYPT_METHOD value: 'SHA512'.
Defaulting to DES.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As described in https://gitlab.com/buildroot.org/buildroot/-/issues/160, the
github mirror is getting shut down - So move to the sourceware.org git repo.
The github mirror was originally used because of performance and reliability
issues with sourceware, but that seems be resolved now after server/RAM
upgrades - E.G. from the sourceware news:
April 22, 2024
server2.sourceware.org now has 512GB RAM, thanks Red Hat.
https://sourceware.org/
So change back to fetch glibc (and localedef) from sourceware.org over git.
Notice: The git archiving leads to slightly different paths and permissions
in the tarball, but the file content is identical:
mkdir a && tar -C a -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125.tar.gz
mkdir b && tar -C b -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125-git4.tar.gz
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien:
- add missing SoB line
- fix command lines in commit log
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Unfortunately, if all optee-related packages are not updated at the same
time, optee-test will not build. This commit bumps all the optee
components at once.
The version bump is needed since optee-examples and optee-test can no
longer compile (compatibility with CMake < 3.5 has been removed from
CMake).
For release details, see:
https://github.com/OP-TEE/optee_os/blob/4.9.0/CHANGELOG.md#op-tee---version-490-2026-01-16
Signed-off-by: Jakob Kastelic <jkastelic@thinksrs.com>
[Julien: add link to release details]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since commit 0e3ddc9dc8 "{linux,
linux-headers}: split hash file in before and from 6.17" there are two
hash file variants, and symlinks for the individual versions. These
were not updated in 48186093fd "bump
5.{10, 15}.x / 6.{1, 6, 12, 18}.x series".
Fixes: 48186093fd
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Swig has a compiled in absolute path to its data files, which can be
overridden using the SWIG_LIB environment variable:
https://github.com/swig/swig/blob/v4.1.1/Source/Modules/main.cxx#L931-L945
This unfortunately means that host-swig misbehaves when used in the SDK, as
this points to the ${HOST_DIR}/bin of the build, which may not be available
when the SDK is used.
The issue was reported upstream but rejected in
https://github.com/swig/swig/issues/253, so instead add a wrapper script
which calculates a sensible SWIG_LIB relative to the wrapper location unless
SWIG_LIB is set, similar to how we do it for E.G. gcc or pkgconf.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add quotes to make shellcheck happy]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit [1] introduced a patch to fix CVE-2025-62291. Since [2] the
security patches neeed to reference the vulnerability with the `CVE: `
trailer in the patch header.
[1] b009935e27 package/strongswan: add patch to fix CVE-2025-62291
[2] 1167d0ff3d docs/manual: mention CVE trailer
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
On Buildroot 2025.05.3, Meson's custom LLVM parser uses llvm-config
with a default search path of /usr/bin, causing it to detect the host
system's llvm-config (version 18.1.3) instead of the buildroot-compiled
one. This forces all LLVM-related packages to match version 18.1.3, but
since the host system lacks llvmspirvlib, the build fails. This patch
forces Meson to use the buildroot-compiled llvm-config.
On the master branch, the meson is somehow able to find the right
llvm-config, so reproduction only seems to be possible if the host
machine ships with a newer version as the one buildroot is using.
llvm-config found: YES
([...]/output/host/bin/llvm-config)
21.1.8
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine,
executionengine, instcombine, irreader, libdriver, linker, lto,
mcdisassembler, mcjit, native, option, scalaropts, target,
transformutils, all-targets, coroutines, frontenddriver, frontendhlsl,
lto, windowsdriver) found: YES 21.1.8
Note that LLVM_CONFIG is a CMake option, not a Meson one. This is because
Meson has custom dependency resolution logic for LLVM (see
https://mesonbuild.com/Dependencies.html#llvm). The EXTRA_BINARIES mechanism
cannot be used here, as it only applies to cross-compilation scenarios, which
does not apply to host-mesa3d builds.
Reproduction (On BR2 tag: 2025.05.3):
BR2_x86_64=y
BR2_x86_atom=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_GLIBC_STABLE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.1.24"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/pc/linux.config"
BR2_LINUX_KERNEL_INSTALL_TARGET=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_LLVM=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_I915=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_IRIS=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
Fixes:
llvm-config found: YES (/usr/bin/llvm-config-18) 18.1.3
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine, executionengine, instcombine, irreader, libdriver, linker, lto, mcdisassembler, mcjit, native, option, scalaropts, target, transformutils, all-targets, coroutines, frontenddriver, frontendhlsl, lto, windowsdriver) found: YES 18.1.3
Dependency LLVMSPIRVLib found: NO. Found 15.0.0.0 but need: '>= 18.1' ; matched: '>= 15.0.0.0', '< 18.2'
Run-time dependency llvmspirvlib found: NO (tried cmake)
output/build/host-mesa3d-25.0.6/meson.build:1882:21: ERROR: Dependency lookup for LLVMSPIRVLib with method 'pkgconfig' failed: Invalid version, need 'LLVMSPIRVLib' ['>= 18.1'] found '15.0.0.0'.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
[Romain:
- Update the commit title
- Update commit log about this issue on master branch
https://lore.kernel.org/buildroot/CACXRmJh1-5Cy92kF9TM5nDs_uB90WAe5iOGmNNL2E-cMhJE7GA@mail.gmail.com/
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Buildroot commit [1] introduced a new Buildroot-Initialize.cmake file,
to mimic the upstream Linux-Initialize.cmake.
However, this upstream file was introduced in commit [2], which was
introduced in CMake 3.27.
When compiling a cmake package on a host with a cmake older than
version 3.27 (for example, the Buildroot Docker reference image has
cmake 3.25), the configuration fails with the error:
CMake Error at /buildroot/output/host/share/buildroot/Platform/Buildroot-Initialize.cmake:1 (include):
include could not find requested file:
Platform/Linux-Initialize
Call Stack (most recent call first):
/usr/share/cmake-3.25/Modules/CMakeSystemSpecificInitialize.cmake:21 (include)
CMakeLists.txt:20 (project)
CMake version < 3.27 is setting its LINUX predefine elsewhere (see
commit log of [1]), so this commit fixes the issue by simply making
the include optional. This will guarante thee cmake predefines will
be present in all the cases.
Fixes:
[1]
[1] ef9f0a07ed
[2] cc737ae829
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The old URL now leads to an HTTP 404 not found error.
Update it to the new one which contains the hashes for the current
release as well as older ones.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The current 'install' target comprises 'install-libs', 'install-apps'
and 'install-docs'.
In our case we don't want to install documentation to the target, so
just run the other two.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
It should be noted that because the python bindings have wrong default
include dirs, they are useless if the includes are not provided
externally.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
