Upstream changed the variables used when outputting version / git commit
info in docker version since:
commit 04b5f44230162de40741acaa0f94c7af6f2fa1d5
Author: Ian Campbell <ijc@docker.com>
Date: Tue Jan 8 15:03:51 2019 +0000
Move versioning variables to a separate package.
This helps to avoid circular includes, by separating the pure data out from the
actual functionality in the cli subpackage, allowing other code which is
imported to access the data.
Signed-off-by: Ian Campbell <ijc@docker.com>
Upstream-commit: 20c19830a95455e8562551aad52c715ad0807cc6
Component: cli
Which is included in docker-cli 19.3.x - So adjust the _CLI_LDFLAGS to match
to get proper docker version output:
Client:
Version: 19.03.11
API version: 1.40
Go version: go1.13.14
Git commit: 19.03.11
vs:
Client:
Version: unknown-version
API version: 1.40
Go version: go1.13.14
Git commit: unknown-commit
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit bf27781bb1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2019-17547: In ImageMagick before 7.0.8-62, TraceBezier in
MagickCore/draw.c has a use-after-free.
- Fix CVE-2019-18853: ImageMagick before 7.0.9-0 allows remote attackers
to cause a denial of service because XML_PARSE_HUGE is not properly
restricted in coders/svg.c, related to SVG and libxml2.
- Update hash of LICENSE file (update in year with
f775a5cf27)
- Update indentation in hash file (two spaces)
- Switch to github helper - it has always been an autogenerated archive.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: use github helper]
(cherry picked from commit 8f2fe00f08)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
HOSTCC may contain spaces, so needs to be quoted.
Most of the places where it is already quoted use double-quotes, so we
use that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 94bb89ad57)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Don't install an incorrect libtool file when building a static library
to fix the following build failure with harfbuzz:
arm-linux-g++.br_real: error: /home/buildroot/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgraphite2.so: No such file or directory
make[5]: *** [main] Error 1
Fixes:
- http://autobuild.buildroot.org/results/9ebe1d11e80755d59190ef2aae82bbba5cc45e44
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit dd2d4caf56)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Switch site to github, here is an extract of
https://sourceforge.net/projects/silgraphite:
"This project has been deprecated. Graphite2, a new version of the
Graphite engine, is available at: https://github.com/silnrsi/graphite
with its own bug tracker."
- graphite2 can be built statically since version 1.3.11 and
2f143c04da
- Update indentation in hash file (two spaces)
Extract from ChangeLog:
1.3.14
. Bug fixes
. Allow features to be hidden (for aliases)
. Move to python3
. Rename doc files from .txt to .asc
1.3.13
. Resolve minor spacing issue in rtl non-overlap kerning
. python3 for graphite.py
. Better fuzzing
. Better building on windows
1.3.12
. Graphite no longer does dumb rendering for fonts with no smarts
. Segment caching code removed. Anything attempting to use the segment cache gets given a regular face instead
. Add libfuzzer support
. Builds now require C++11
. Improvements to Windows 64 bit builds
. Support different versions of python including 32 bit and python 3
. Various minor bug fixes
1.3.11
. Fixes due to security review
. Minor collision avoidance fixes
. Fix LZ4 decompressor against high compression
The fixes due to security review are a little bit vague, a quick search
on github seems to indicate that those issues could be related to
segcache which has been removed since version 1.3.12:
https://github.com/silnrsi/graphite/search?q=security&type=Issuesb0f77e4a9d
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit d3a06c2fc4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
uclibc is part of the toolchain, and as such does not have a dependency
on it. As a consequence, it does not have a dependency on host-ccache,
when this is needed.
Usually, host-ccache is built before uclibc, as part of the dependency
of gcc-initial, host-binutils, and a few other host packages that are
built before uclibc.
However, during top-level parallel builds, this ordering is only ever
guaranteed at the beginning of the configure step, and not before.
But for kconfig-packages, the moment we apply the configuration to
prepare the .config file is a pseudo step that happens somewhere in
limbo between the patch step and the configure step. As such, the
build ordering that is otherwise guaranteed by the _DEPENDENCIES is not
applicable yet.
And so, with top-level parallel builds with ccache enabled, there is
nothing that guarantees host-ccache to be built and installed by the
time we are trying to generate uclibc's .config file, which can be quite
early in the build process, and thus the build fails:
/home/raphael/github/ftcommunity-TXT/buildroot-rootfs/output/per-package/uclibc/host/bin/ccache /usr/bin/gcc /home/raphael/github/ftcommunity-TXT/buildroot-rootfs/output/build/uclibc-1.0.34/extra/config/conf.c -c -o ../../extra/config/conf.o -Os -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE -DKBUILD_NO_NLS -DCONFIG_='""' -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE -DKBUILD_NO_NLS -DCONFIG_='""'
/bin/sh: 1: /home/raphael/github/ftcommunity-TXT/buildroot-rootfs/output/per-package/uclibc/host/bin/ccache: not found
make[2]: *** [Makefile:64: ../../extra/config/conf.o] Error 127
make[1]: *** [Makefile.in:475: extra/config/conf] Error 2
make[1]: Leaving directory '/home/raphael/github/ftcommunity-TXT/buildroot-rootfs/output/build/uclibc-1.0.34'
make: *** [package/uclibc/uclibc.mk:458: /home/raphael/github/ftcommunity-TXT/buildroot-rootfs/output/build/uclibc-1.0.34/.stamp_dotconfig] Error 2
make: *** Waiting for unfinished jobs....
The root cause is that uclibc sets;
UCLIBC_KCONFIG_OPTS = $(UCLIBC_MAKE_FLAGS) [...]
with:
UCLIBC_MAKE_FLAGS = [...] HOSTCC="$(HOSTCC)"
And then the kconfig-package infra calls to the configurators,
menuconfig, xconfig et al, but also olddefconfig et al.. with:
[...] $($(1)_MAKE) [...] $(PKG_KCONFIG_COMMON_OPTS) $($(1)_KCONFIG_OPTS) [...]
with (note a latent bug in there, will be fixed in another patch):
PKG_KCONFIG_COMMON_OPTS = HOSTCC=$(HOSTCC_NOCCACHE)
So, a HOSTCC as set by a package will always win onver the one set by
the infra, which is exactly what we want.
But in this case, uclibc sets HOSTCC so that it can build its host tools
needed during the build, and in doing so uses the ccache-enabled host c
compiler. Which might not yet be available for the kconfig-package infra
to generate the .config file.
We had a similar (non-)issue for the linux package, which was fixed in
commit 71a31b2357 (linux: use HOSTCC_NOCCACHE as kconfig HOSTCC).
But here, uclibc does not have the toolchain in its dependencies (as said
earlier, uclibc *is* part of the toolchain).
Since the host compiler is only used to build very few files to generate
the simple executable needed to generate the .config file, doing without
the ccache-enabled host compiler will be amply enough.
So, we override HOSTCC in UCLIBC_KCONFIG_OPTS, to use the non-cached
host compiler.
Note that, in a first approximation, one would be tempted to change the
ordering in the kconfig-package infra:
$($(1)_KCONFIG_OPTS) $(PKG_KCONFIG_COMMON_OPTS)
so that the non-cached HOSTCC always wins over the cached one. But this
would be incorrect, in cases where the package really needs to override
HOSTCC; indeed we want the package-provided values to always win over
the default ones providing by the infra.
Reported-by: Raphael Jacob <r.jacob2002@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 689fe66100)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The kconfig mangling macros currently operate on the caller-supplied
.config file, on the assumption that the caller will always know what
file to mangle.
This was correct so far, as packages would indeed only mangle their
own .config files.
However, the Linux kernel does its mangling based on whether some
other packages are enabled or not. That list of conditional mangling
is getting bigger and bigger with each new package that needs such
mangling, culminating with the pending firewalld one [0]. Furthermore,
this mangling is not accessible to packages in br2-external trees. So
we'll want to have packages provide the mangling commands.
So we'll want the mangling to be done on the Linux' .config file in
the expanding package context, not in the package calling the macros.
But packages do not, and should not have knowledge about where the
.config file is, nor how it is named.
So we make the parameter to specify the .config file to mangle
optional. If it is set, this is what the macros will mangle; if it is
not set, the expanding package's .config file will be used.
This has the added benefit that we do not have to repeat in the
expanding package context the knowledge of how the .config file is
named:
FOO_KCONFIG_DOTCONFIG = .config
define FOO_KCONFIG_FIXUPS_CMDS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 21e69972bf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we have three macros that may mangle a .config file. All
three are modeled after the same pattern: removing the existing option
from the .config file, then adding the new definition for that option;
all three also implement that pattern with the same commands: sed and
echo.
This is all good so far, because it was simple enough, and they always
worked on a file passed in parameter.
However, we're soon going to change this file parameter to make it
optional, so that the file will then be auto-deduced for the current
package. In that case, the file to sed and echo into will be a more
complex structure than just the parameter.
As such, move the actual mangling down to a helper macro, that is called
from the three existing ones.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 653afb764a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In 4fc62e1eb6, we removed arch/toolchain
dependencies from the mosquitto library (MMU, !STATIC, SYNC4), and moved
them to the mosquitto broker only.
All the packages modified here only need the mosquitto library, so they
shouldn't have those depends anymore; but this was never done before.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
[Peter: leave mmu/!static dependency for domoticz as it uses fork()/looks
for libmosquitto.so]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8f5a9f597e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If the modules directory that corresponds to the version of the kernel
being built has been deleted, don't try to run depmod, which will
obviously fail.
This can happen for instance when the modules are stripped from the main
root filesystem, and placed into a separate filesystem image, so that
the root filesystem and the kernel can be updated separately.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 532fe9fb57)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 98a6f1fc02 (fs/cpio: make initramfs init script survive 'console='
kernel argument) dropped the explicit /dev/console execs for fd 0,1,2, as
they fail when booted with console= and aren't really needed as the kernel
will setup fd 0,1,2 from /dev/console before executing the initramfs anyway.
Not doing this unfortunately confuses glibc's ttyname_r(3) implementation
(used by E.G. busybox/coreutils 'tty'), causing it to fail with ENOENT as
it does a fstat on fd 0 and tries to match up st_ino / st_dev against the
entries in /dev (since glibc 2.26):
commit 15e9a4f378c8607c2ae1aa465436af4321db0e23
Author: Christian Brauner <christian.brauner@canonical.com>
Date: Fri Jan 27 15:59:59 2017 +0100
linux ttyname and ttyname_r: do not return wrong results
If a link (say /proc/self/fd/0) pointing to a device, say /dev/pts/2, in a
parent mount namespace is passed to ttyname, and a /dev/pts/2 exists (in a
different devpts) in the current namespace, then it returns /dev/pts/2.
But /dev/pts/2 is NOT the current tty, it is a different file and device.
Detect this case and return ENODEV. Userspace can choose to take this as a hint
that the fd points to a tty device but to act on the fd rather than the link.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The reason it fails is that we manually mount devtmpfs on /dev in /init, so
the /dev/console used by the kernel (in rootfs) is not the same file as
/dev/console at runtime (in devtmpfs).
Notice: Once logged in, tty does work correctly. Presumably login reopens
stdin/stdout/stderr.
To fix this, re-add the exec of /dev/console for fd 0,1,2, but only do so if
possible. Because of the above mentioned shell behaviour (specified by
POSIX [0]), perform this check in a subshell.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_20_01
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit b9026e83f9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-14349: It was found that PostgreSQL versions before 12.4,
before 11.9 and before 10.14 did not properly sanitize the search_path
during logical replication. An authenticated attacker could use this
flaw in an attack similar to CVE-2018-1058, in order to execute
arbitrary SQL command in the context of the user used for replication.
- Fix CVE-2020-14350: It was found that some PostgreSQL extensions did
not use search_path safely in their installation script. An attacker
with sufficient privileges could use this flaw to trick an
administrator into executing a specially crafted script, during the
installation or update of such extension. This affects PostgreSQL
versions before 12.4, before 11.9, before 10.14, before 9.6.19, and
before 9.5.23.
https://www.postgresql.org/docs/12/release-12-4.html
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 35ebee6510)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As 18f6c26118 just did to silence the file lists commands, switch to
using $(Q) instead of a plain @, to silence the commands.
Using $(Q) will allow to debug the commands with V=1.
We keep @ for the calls to MESSAGE, though.
The commands that are not currently silenced are left as-is, and they
can be converted to being silent in a followup patch, if need be,
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5754d9c9b1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 0e2be4db8a
("package/pkg-generic: make file list logic parallel build
compatible"), the commands executed at the every end of the build
to assemble the list of files installed by the different packages
are visible in the make output. They are quite noisy, and clutter
the output.
The other commands in target-finalize are also hidden using "@",
so we should also do the same for those commands. But that hurts
debuggability, so we use $(Q) (the existing '@'s can be changed
in a followup patch).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: use '$(Q)', not '@']
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 18f6c26118)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
arm: CVE-2020-6096: Fix multiarch memcpy for negative length [BZ #25620]
Unsigned branch instructions could be used for r2 to fix the wrong behavior
when a negative length is passed to memcpy.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
wolfSSL version 4.5.0 contains 6 vulnerability fixes: 2 fixes for TLS 1.3,
2 side channel attack mitigations, 1 fix for a potential private key leak
in a specific use case, 1 fix for DTLS including those 3 CVEs:
- Fix CVE-2020-12457: An issue was discovered in wolfSSL before 4.5.0.
It mishandles the change_cipher_spec (CCS) message processing logic
for TLS 1.3. If an attacker sends ChangeCipherSpec messages in a
crafted way involving more than one in a row, the server becomes stuck
in the ProcessReply() loop, i.e., a denial of service.
- Fix CVE-2020-15309: An issue was discovered in wolfSSL before 4.5.0,
when single precision is not employed. Local attackers can conduct a
cache-timing attack against public key operations. These attackers may
already have obtained sensitive information if the affected system has
been used for private key operations (e.g., signing with a private
key).
- Fix CVE-2020-24585: An issue was discovered in the DTLS handshake
implementation in wolfSSL before 4.5.0. Clear DTLS application_data
messages in epoch 0 do not produce an out-of-order error. Instead,
these messages are returned to the application.
Also update hash of LICENSING as well as WOLF_LICENSE due to later
verbage update with
970391319bhttps://www.wolfssl.com/docs/security-vulnerabilities/
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 0ed8bf6d2b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On Ubuntu 18.04, make-4.1 emits spurious, incorrect "entering/leaving"
messages, which end up in the LINUX_VERSION_PROBED variable:
printf 'probed linux version: "%s"\n' "$(LINUX_VERSION_PROBED)"
probed linux version: "make[1]: Entering directory '/home/buildroot'
4.19.78-linux4sam-6.2
make[1]: Leaving directory '/home/buildroot/output/build/linux-linux4sam_6.2'"
First, the messages are displayed even though we do explicitly pass
--no-print-directory -s.
Second, the entering and leaving messages are not about the same
directory!
This *only* occurs in the following conditions:
- the user has the correct 0022 umask,
- top-level parallel is used (with or without PPD),
- initial -C is specified as well.
$ umask 0022
$ make -j16 -C $(pwd)
[...]
depmod: ERROR: Bad version passed make[1]:
[...]
(yes, 'make[1]:' is the string depmod is trying, and fails, to parse as
a version string).
If any of the three conditions above is removed, the problem no longer
occurs. Here's a table of the MAKEFLAGS:
| 0002 | 0022 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | |
noC | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | w |
-C | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | w -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
0002: umask == 0002
0022: umask == 0022
no-j: no -j flag
-j16: -j16 flag
noC: no -C flag
-C : -C /path/of/buildroot/
Only the bottom-right-most case fails...
This behaviour goes against what is documented:
https://www.gnu.org/software/make/manual/make.html#g_t_002dw-Option
5.7.4 The ‘--print-directory’ Option
[...]
you do not need to specify this option because ‘make’ does it for
you: ‘-w’ is turned on automatically when you use the ‘-C’ option,
and in sub-makes. make will not automatically turn on ‘-w’ if you
also use ‘-s’, which says to be silent, or if you use
‘--no-print-directory’ to explicitly disable it.
So this exactly describes our situation; yet 'w' is added to MAKEFLAGS.
Getting rid of the 'w' flag makes the build succeed again, so that's
what we do here (bleark, icky)...
Furthermore, the documented way to override MAKEFLAGS is to do so as a
make parameter:
https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
5.7.3 Communicating Options to a Sub-make
[...]
If you do not want to pass the other flags down, you must change the
value of MAKEFLAGS, like this:
subsystem:
cd subdir && $(MAKE) MAKEFLAGS=
However, doing so does not fix the issue. So we resort to pass the
modified MAKEFLAGS via the environment (bleark, icky)...
Fixes: #13141
Reported-by: Laurent <laurent@neko-labs.eu>
Reported-by: Asaf Kahlon <asafka7@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3f6a40e9fa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2020-24332
If the tcsd daemon is started with root privileges,
the creation of the system.data file is prone to symlink attacks
CVE-2020-24330
If the tcsd daemon is started with root privileges,
it fails to drop the root gid after it is no longer needed
CVE-2020-24331
If the tcsd daemon is started with root privileges,
the tss user has read and write access to the /etc/tcsd.conf file
For details, see the advisory:
https://www.openwall.com/lists/oss-security/2020/05/20/3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e71be18354)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2019-5163: An exploitable denial-of-service vulnerability
exists in the UDPRelay functionality of Shadowsocks-libev 3.3.2. When
utilizing a Stream Cipher and a local_address, arbitrary UDP packets
can cause a FATAL error code path and exit. An attacker can send
arbitrary UDP packets to trigger this vulnerability.
- Fix CVE-2019-5164: An exploitable code execution vulnerability exists
in the ss-manager binary of Shadowsocks-libev 3.3.2. Specially crafted
network packets sent to ss-manager can cause an arbitrary binary to
run, resulting in code execution and privilege escalation. An attacker
can send network packets to trigger this vulnerability.
Also update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit fd3dd9d9c5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2020-15389: jp2/opj_decompress.c in OpenJPEG through 2.3.1 has a
use-after-free that can be triggered if there is a mix of valid and
invalid files in a directory operated on by the decompressor. Triggering
a double-free may also be possible. This is related to calling
opj_image_destroy twice.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b006cc373f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2020-12762: json-c through 0.14 has an integer overflow and
out-of-bounds write via a large JSON file, as demonstrated by
printbuf_memappend.
Also update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 071e719d58)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Notes:
- json-c now uses cmake instead of autoconf
- This version also brings support to the much welcomed feature for
parsing uint64_t types
Signed-off-by: Christopher Pelloux <git@chp.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 7b4581cca8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our patch
0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch adds
an option --make-rpath-relative, which we use to tweak RPATH of target
binaries.
However, one of the effect of this option is that it drops RPATH
entries if the corresponding directory does not contain a library that
is referenced by a DT_NEEDED entry of the binary.
This unfortunately isn't correct, as RPATH entries are not only used
by the dynamic linker to resolve the location of libraries listed
through DT_NEEDED entries: RPATH entries are also used by dlopen()
when resolving the location of libraries that are loaded at runtime.
Therefore, the removal of RPATH entries that don't correspond to
directories containing libraries referenced by DT_NEEDED entries break
legitimate uses of RPATH for dlopen()ed libraries.
This issue was even pointed out during the review of the upstream pull
request:
https://github.com/NixOS/patchelf/pull/118#discussion_r329660138
This fixes tst-origin uClibc-ng unit test:
https://github.com/wbx-github/uclibc-ng-test/blob/master/test/dlopen/Makefile.in#L25https://github.com/wbx-github/uclibc-ng-test/blob/master/test/dlopen/tst-origin.c#L15
Without this patch:
$ gcc -o toto toto.c -Wl,-rpath,/tmp/test/bar
$ readelf -d toto | grep PATH
0x000000000000000f (RPATH) Library rpath: [/tmp/test/bar]
$ ./output/host/bin/patchelf --debug --make-rpath-relative /tmp/
toto
patching ELF file `toto'
Kernel page size is 4096 bytes
removing directory '/tmp/test/bar' from RPATH because it does not contain needed libs
new rpath is `'
$ readelf -d toto | grep PATH
0x000000000000001d (RUNPATH) Library runpath: []
With the patch applied:
$ gcc -o toto toto.c -Wl,-rpath,/tmp/test/bar
$ readelf -d toto | grep PATH
0x000000000000000f (RPATH) Library rpath: [/tmp/test/bar]
$ ./output/host/bin/patchelf --debug --make-rpath-relative /tmp/ toto
patching ELF file `toto'
Kernel page size is 4096 bytes
keeping relative path of /tmp/test/bar
new rpath is `test/bar'
$ readelf -d toto | grep PATH
0x000000000000001d (RUNPATH) Library runpath: [test/bar]
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit bcdb74512d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security vulnerabilities:
CVE-2020-12695: The Open Connectivity Foundation UPnP specification before
2020-04-17 does not forbid the acceptance of a subscription request with a
delivery URL on a different network segment than the fully qualified
event-subscription URL, aka the CallStranger issue.
For details, see the advisory:
https://w1.fi/security/2020-1/upnp-subscribe-misbehavior-wps-ap.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9b020359b1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There is no debug profile on cargo. The available profiles are: dev
(enabled by default), release, test and bench.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit ec5b470710)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
