- Fix CVE-2022-1114: A heap-use-after-free flaw was found in
ImageMagick's RelinquishDCMInfo() function of dcm.c file. This
vulnerability is triggered when an attacker passes a specially crafted
DICOM image file to ImageMagick for conversion, potentially leading to
information disclosure and a denial of service.
- Fix CVE-2022-32545: A vulnerability was found in ImageMagick, causing
an outside the range of representable values of type 'unsigned char'
at coders/psd.c, when crafted or untrusted input is processed. This
leads to a negative impact to application availability or other
problems related to undefined behavior.
- Fix CVE-2022-32546: A vulnerability was found in ImageMagick, causing
an outside the range of representable values of type 'unsigned long'
at coders/pcl.c, when crafted or untrusted input is processed. This
leads to a negative impact to application availability or other
problems related to undefined behavior.
- Fix CVE-2022-32547: In ImageMagick, there is load of misaligned
address for type 'double', which requires 8 byte alignment and for
type 'float', which requires 4 byte alignment at
MagickCore/property.c. Whenever crafted or untrusted input is
processed by ImageMagick, this causes a negative impact to application
availability or other problems related to undefined behavior.
- Update hash of LICENSE (year updated with
80629dfb3f)
https://github.com/ImageMagick/Website/blob/main/ChangeLog.md
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
ualpn is not compatible with libressl as stated by upstream in
32546c7caa
resulting in the following build failure:
ualpn.c: In function 'ssl_client_hello_cb':
ualpn.c:2038:16: error: 'SSL_CLIENT_HELLO_RETRY' undeclared (first use in this function); did you mean 'SSL_F_CLIENT_HELLO'?
2038 | return SSL_CLIENT_HELLO_RETRY;
| ^~~~~~~~~~~~~~~~~~~~~~
| SSL_F_CLIENT_HELLO
Fixes:
- http://autobuild.buildroot.org/results/d7d49cfce6f99c59e99c8e15399164fd5ecacc21
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In 96c3b52132 (package/uacme: don't allow ualpn with mbedTLS), the
preference order moved openssl before mbedtls, because ualpn was not
compatible with mbedtls. That caused the preference order in the .mk to
diverge semantically from the preference order in the Config.in.
Indeed, openssl is only selected when neither gnutls nor mbedtls are
enabled, so openssl is clearly leastpreferred crypto backend. But when
both openssl and mbedtls were enabled, then uacme would use opensslC
because of ualpn.
The ualpn limitation was lifted in 6c7b46945e (package/uacme: allow
ualpn with mbedTLS), but the preference order in the .mk was not
restored to match that of the Config.in.
Restore the order in the .mk so that openssl is again treated as the
least-preferred crypto backend.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- split off to its own patch
- write the full commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit aaced92e8c.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 115ee05214.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit f8528acdfd.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 23329364e2.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update fourth patch to avoid the following build failure with webrtc
raised since commit a40a516c8a:
../output-1/build/pulseaudio-16.1/src/modules/echo-cancel/meson.build:13:0: ERROR: No host machine compiler for 'src/modules/echo-cancel/webrtc.cc'
That is because we removed the C++ language from the global meson.build.
Add it back to the local meson.build in echo-cancel.
The echo-cancel module is always built, but the echo-cancel meson.build
is only included if webrtc-aec is enabled. We only enable it when
webrtc-audio-processing is selected, and that package depends on C++.
Therefore, it is safe to depend on C++ in the echo-cancel meson.build.
Fixes:
- http://autobuild.buildroot.org/results/e60d72268667ed57a254d7552fa2d785e2e21726
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
- Drop default value of BR2_PACKAGE_XENOMAI_REPOSITORY
- Add BR2_PACKAGE_XENOMAI_{CUSTOM_VERSION_VALUE,REPOSITORY_VERSION} to
mimick what is done by other packages (e.g. barebox, u-boot)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
netsniff-ng unconditionally uses pthread_spin_lock since its addition in
commit 500d287b07 and
1a9fbac03c
resulting in the following build failure:
/home/autobuild/autobuild/instance-1/output-1/per-package/netsniff-ng/host/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/10.3.0/../../../../x86_64-buildroot-linux-uclibc/bin/ld: netsniff-ng/tprintf.o: in function `tprintf_flush':
tprintf.c:(.text+0x42c): undefined reference to `pthread_spin_lock'
Fixes:
- http://autobuild.buildroot.org/results/ceadbdea8cc35bfd7d601a6d4b18137f81f61406
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure without threads raised since bump to
version 9.21.4 in commit e4c81885ed:
CompactDisplay.cpp:13:14: fatal error: pthread.h: No such file or directory
13 | #include <pthread.h>
| ^~~~~~~~~~~
For an unknown reason, previously drbdmon (which unconditionally uses
threads) was always wrongly disabled:
configure:5846: checking whether /home/fabrice/buildroot/output/host/bin/arm-linux-g++ supports C++11 features by default
configure:6141: /home/fabrice/buildroot/output/host/bin/arm-linux-g++ -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.cpp >&5
configure:6141: $? = 0
configure:6149: result: yes
configure:6824: WARNING: No C++11 compiler found, disabling drbdmon build.
The correct activation of drbdmon could be a side-effect of
b235e83409
Fixes:
- http://autobuild.buildroot.org/results/2cc7d771176ccde7539cc93d83e9621d9ada8357
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Github repository mripard/sunxi-mali states to use Lima in place of
sunxi-mali because it's deprecated, but this package is still useful in
Buildroot so I want to move the SITE to my Github fork of the original
repository that already contains a patch to fix a build failure showing
up with Linux version >= 5.15.
The upstream patch fixes missing DMA_BUF module inclusion that leads to
build failure. The patch includes DMA_BUF by using:
MODULE_IMPORT_NS(DMA_BUF);
My idea is to continue to maintain this package in parallel to Lima since
it seems to be still useful.
Fixes:
http://autobuild.buildroot.net/results/8f25c26de737c358b3b43a10737609465b4e1398/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Set CROSS variable otherwise makedumpfile will use it to undefine the
host architecture through -U__$(HOST_ARCH)__ if $(TARGET) is not equal
to $(HOST_ARCH). This will result in the following build failure since
the addition of the package in commit
adb64a97e7 if aarch64_be is cross-compiled
on a aarch64 host for example:
/home/autobuild/autobuild/instance-5/output-1/host/bin/aarch64_be-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -g0 -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVERSION='"1.7.0"' -DRELEASE_DATE='"8 Nov 2021"' -D__aarch64_be__ -U__aarch64__ -DUSELZO -c -o ./print_info.o print_info.c
[...]
makedumpfile.c: In function 'is_kvaddr':
makedumpfile.c:1547:46: error: 'KVBASE' undeclared (first use in this function)
1547 | return (addr >= (unsigned long long)(KVBASE));
| ^~~~~~
Fixes:
- http://autobuild.buildroot.org/results/e4e10364e1a24099ce31bf20eacf5adedf93e5a7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 4dff1be05e (package/libvirt: libvirtd needs C++ for nmap-ncat)
introduce a recursive dependency (really: a circular dependency):
package/busybox/Config.in:33:error: recursive dependency detected!
package/busybox/Config.in:33: symbol BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected by BR2_PACKAGE_EBTABLES_UTILS_SAVE
package/ebtables/Config.in:11: symbol BR2_PACKAGE_EBTABLES_UTILS_SAVE depends on BR2_PACKAGE_EBTABLES
package/ebtables/Config.in:1: symbol BR2_PACKAGE_EBTABLES is selected by BR2_PACKAGE_LIBVIRT_DAEMON
package/libvirt/Config.in:44: symbol BR2_PACKAGE_LIBVIRT_DAEMON depends on BR2_PACKAGE_NETCAT_OPENBSD
package/netcat-openbsd/Config.in:1: symbol BR2_PACKAGE_NETCAT_OPENBSD depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
We can't drop the C++ dependency and switch the netcat-openbsd and
nmap-ncat dependencies conditions without adding a glibc dependency.
So always mandate C++ even if is only needed by nmap and not
netcat-openbsd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 'dc7ca780a0 package/gstreamer1/gst1-plugins-good: convert package
type to meson' from 2019 removed the symbol, stating:
Remove BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
Existing configs will already have BR2_PACKAGE_ZLIB selected, so no
legacy entry is needed for BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
So drop the reference to the symbol.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
These inexistent symbols are referenced since 2014, from commit:
'aa441aa84c openocd: bump to version 0.8.0'
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The typo was added in 2018 by commit
'f3da9ffff0 package/busybox: invert dependency with netcat-openbsd'
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since this commit from 2010:
'87b81bb56f toolchain: move sysroot to host dir'
BR2_STAGING_DIR does not exist anymore.
So fix the typo added in 2014 with commit:
8956c336eb package/qemu: add SDL frontends
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_sparc_v7 was removed in 2013 in commit '16bcf46a63 arch/sparc: drop
old SUN-specific variants'.
BR2_sparc_sparchfleon and BR2_sparc_sparchfleonv8 were moved to legacy
handling in 2014 in commit '43b78e7285 arch: sparc: Add leon3 cpu type
and remove sparc{s,h}fleon{,v8}' and later removed from legacy handling
in 2020.
So drop the remaining references for these symbols.
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
