Release notes:
https://lists.gnu.org/archive/html/bug-wget/2024-11/msg00002.html
Fixes the following vulnerabilities:
- CVE-2024-38428: url.c in GNU Wget through 1.24.5 mishandles semicolons in
the userinfo subcomponent of a URI, and thus there may be insecure
behavior in which data that was supposed to be in the userinfo
subcomponent is misinterpreted to be part of the host subcomponent.
https://nvd.nist.gov/vuln/detail/CVE-2024-38428
- CVE-2024-10524: Applications that use Wget to access a remote resource
using shorthand URLs and pass arbitrary user credentials in the URL are
vulnerable. In these cases attackers can enter crafted credentials which
will cause Wget to access an arbitrary host.
https://www.openwall.com/lists/oss-security/2024/11/18/6
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 295b2c4f8e)
[Peter: mark as security bump]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In some specific situations, there is subtle bugs which depends on a
specific Qemu emulator version and the code it runs.
For example, EDK2 on Aarch64 could work with specific versions of Qemu,
EDK2 and ATF. See commit cc0823c2d "boot/edk2: bump to version
edk2-stable202405" [1].
Also, some Qemu bugs made the guest OS crash. See for example commit
9534b9c00 "package/qemu: fix qemu 9.x issue for AArch32 Secure
PL1&0" [2].
Commit 0d4177598 "support/testing/infra/emulator.py: add build host
dir to qemu search path" added the ability for a runtime test to
select host-qemu in order to use it. It is also possible for a user
to use the "utils/run-tests" script on its host system providing its
own version of Qemu. The Buildroot CI can also use its Qemu version
included in the reference Docker image.
This means the Qemu emulator for running a runtime test can be from
several sources:
- Buildroot Docker reference image,
- Buildroot host-qemu package version,
- Developer host OS qemu version.
Those versions can also change in time.
In order to help debugging of those subtle emulator bugs, this commit
adds a recording of the actual Qemu version used to run a test.
[1] cc0823c2d1
[2] 9534b9c00c
[3] 0d4177598c
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ed9da08944)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The SBSA Reference Platform was updated to use the neoverse-n1 cpu
(armv8.2a) in Qemu v8.1 [1].
Commit c58a2a968 "configs/qemu_aarch64_sbsa_defconfig: switch to
neoverse-n1 (armv8.2a)" [2] reflected this change in
qemu_aarch64_sbsa_defconfig.
This commit updates the test_fwts runtime test the same way.
This update is possible with the help of commits [3] and [4].
[1] 1877272bad
[2] c58a2a9687
[3] 0d4177598c
[4] 027ddcbff6
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit c2f91e9046)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The SBSA Reference Platform was updated to use the neoverse-n1 cpu
(armv8.2a) in Qemu v8.1 [1].
Commit c58a2a968 "configs/qemu_aarch64_sbsa_defconfig: switch to
neoverse-n1 (armv8.2a)" [2] reflected this change in
qemu_aarch64_sbsa_defconfig.
This commit updates the test_edk2 runtime test the same way.
This update is possible with the help of commits [3] and [4].
[1] 1877272bad
[2] c58a2a9687
[3] 0d4177598c
[4] fba62f2ab1
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 36c7a5366a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The weston runtime test is unreliable, depending on the execution speed
of its runner. Example of failure is [1], and success is [2]. This
commit improves the test in several ways, to make it more robust to
execution speed variations:
- The command started in background (weston, weston-simple-egl) are
now started in a subshell. This suppresses the job control messages
when they are stopped. Those messages could interfere with the parsing
of the output;
- Wait time are moved outside the emulator;
- The kernel argument vt.global_cursor_default=0 is added, to make sure
cursors are globally disabled, since the test use vkms display CRCs;
- The memory of the emulator is increased to 512M. This test uses cpio
initramfs, and the filesystem size increased;
- The vkms driver emulates a "vsync" event, but can generate a warning
when the system is too slow. This warning is printed on the console by
the klogd daemon in its default configuration. This commit adds the
overlay file /etc/default/klogd to limit only kernel emergency
messages to be printed on the console. This change fixes the failure
seen in [1] ;
- Some sleep time values were adjusted to run on a "performant" idle
host. Those values are not suitable in all situations. In the
meantime a generic retry mechanism is added in the test infra, this
commit adds a retry logic inspired from the test_flutter runtime
test.
Fixes: [1]
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/8562483474
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/8435236652
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The lmbench package (largely unmaintained upstream, last release in
2006) uses a home-grown build system. The scripts/build script sets
LDLIBS to -lm and Buildroot's makefile changes that to:
LDLIBS+=-lm
Except that when Buildroot passes LDLIBS="`$(PKG_CONFIG_HOST_BINARY)
--libs libtirpc`", the LDLIBS variable ends up being equal to:
-ltirpc-lm
Yes, without any space between -ltirpc and -lm.
Due to this, the checks in scripts/build that use ${LDLIBS} all fail,
and in particular the test that checks when socklen_t is a known type
fails, causing lmbench to provide its own definition, which clashes
with the C library headers definition, and therefore causing build
failures such as:
bench.h:81:13: error: conflicting types for 'socklen_t'; have 'int'
This commit fixes that by adjusting scripts/build using a patch to
properly allow passing additional ${LDLIBS} value, with the needed
space to separate the value from -lm.
Fixes:
http://autobuild.buildroot.net/results/f1715de95b46a1d08143e529bd4574bc7dbcfb3e/
We have been unable to determine exactly when this issue was
introduced. The first build failure we could find is the one
referenced above, which dates back from Aug 19, 2024. Since this date,
lmbench has been consistently failing on a very regular
basis. However, prior to Aug 19, 2024, the previous failure was from
December 2022, and was unrelated. It is unclear what changed in Aug
2024 to cause this issue to surface. The one thing that changed right
before commit ce3dedc2 (first failing commit) are changes to
genrandconfig, which ensures all autobuilders now generated fully
random configurations instead of configurations based on a
well-defined list of arch/toolchain configurations. But even with
this, this lmbench issue should have appeared earlier, and we have
been unable to find a scientific explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
