What key is used to sign sstate artefacts should not affect the hash of
the object, otherwise everyone would need to use the same signing key.
(From OE-Core rev: 01a9358abe821c1da06c3243ccbcc93348042937)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running:
execute_pre_post_process(d, d.getVar(ROOTFS_POSTPROCESS_COMMAND))
rootfs_update_timestamp is run, which assumes that rootfs/${sysconfdir}
is already created (usually done through the do_rootfs task on linux).
This causes the build to fail if ${sysconfdir} does not exist.
This may be overlooked if debug-tweaks is enabled since some other
commands are added, one of which creates the required path
(see postinst_enable_logging).
See [1] for more info:
[1] https://github.com/aehs29/meta-freertos/issues/4
(From OE-Core rev: 179a912bf10ba02448e8d603043c454ca678ac60)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen three hangs in cgroup_xattr and two in proc01 so far. The new
plan is just to disable any tests seen to hang. I've had enough of these
causing problems on our testing infrastructure.
(From OE-Core rev: 622b1a409aaa8fd895821a53ee5db33206b98825)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream commit:
This is related to parameter entities expansion and following
the line of the billion laugh attack. Somehow in that path the
counting of parameters was missed and the normal algorithm based
on entities "density" was useless.
CVE: CVE-2021-3541
Upstream-Status: Backport [8598060bac]
(From OE-Core rev: e1e04de65e24d1596d800d7f8e85f98bb7f72632)
Signed-off-by: Tony Tascioglu <tony.tascioglu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch fixes CVE-2021-3518. The fix for the CVE is the
following 3 lines in 1098c30a:
- (cur->children->type != XML_ENTITY_DECL) &&
- (cur->children->type != XML_XINCLUDE_START) &&
- (cur->children->type != XML_XINCLUDE_END)) {
+ ((cur->type == XML_DOCUMENT_NODE) ||
+ (cur->type == XML_ELEMENT_NODE))) {
This relies on an updated version of xinclude.c from upstream which
also adds several new tests. Those changes are brought in first so
that the CVE patch can be applied cleanly.
The first patch updates xinclude.c and adds the new tests from
upstream, and the second applies the fix for the CVE.
CVE: CVE-2021-3518
Upstream-Status: Backport
[1098c30a04]
(From OE-Core rev: 6c59d33ee158129d5c0cca3cce65824f9bc4e7e3)
Signed-off-by: Tony Tascioglu <tony.tascioglu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Parsing specially crafted Mixed Content while parsing XML data may
lead to invalid data structure being created, as errors were not
propagated. This could lead to several NULL Pointer Dereference when
post-validating documents parsed in recovery mode.
CVE: CVE-2021-3537
Upstream-Status: Backport [babe75030c]
(From OE-Core rev: 6d69f7453f78dcb19f472dcea183e859648c5243)
Signed-off-by: Tony Tascioglu <tony.tascioglu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before, ccache's configure stage built HTML documentation and man pages
depending on if asciidoc is installed. This patch makes it configurable.
Pass the new cmake option ENABLE_DOCUMENTATION along and add the
asciidoc dependency if necessary.
This fixes an issue when ccache's configure stage found asciidoc/a2x on
the system outside of the sysroot (e.g. installed via 'apt install
asciidoc'). ccache would then decide to build docs and manual pages, but
would fail during compilation: the system's a2x could not find the
system's asciidoc because it did not reside in the set PATH.
By enabling/disabling docs/man page generation explicitly and adding
asciidoc to DEPENDS as necessary, this is no longer an issue.
[ This corresponds to commit b0aedd74 and parts of commit 1eedc5f8,
with the patch replaced by the upstream version. ]
(From OE-Core rev: 3ca3c890834152597d8440b77e3d2767ca72c7a6)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under certain build patterns, warnings about missing manifests can appear. These
are real issues where the manifest was removed and shouldn't have been.
Martin Jansa was able to find a reproducer of:
MACHINE=qemux86 bitbake zlib-native
echo 'PR = "r1"' >> meta/recipes-core/zlib/zlib_1.2.11.bb
MACHINE=qemux86-64 bitbake zlib-native
MACHINE=qemux86 bitbake zlib-native
<the zlib-native manifest is now removed along with the sysroot-components contents>
The code maintains a per machine list of stamps but a per PACAGE_ARCH list of
stamp/manifest/workdir mappings. The latter is only appended to for speed with
the assumption that once stamps are gone, the code wouldn't trigger.
The code only ever appends to the mapping list (for speed/efficency under lock)
meaning that multiple entries can result where the stamp/workdir differs due to
version changes but the manifest remains the same.
By switching MACHINE part way through the build, the older stamp is referenced
and the manifest is incorrectly removed as it matches an now obsolete entry in
the mapping file.
There are two possible fixes, one is to rewrite the mapping file every time
which means adding regexs, iterating and generally complicating that code. The
second option is to only use the last mapping entry in the file for a given
manifest and ignore any earlier ones. This patch implments the latter.
Also drop the stale entries if we are rewriting it.
(From OE-Core rev: fe468802f697d0be41cf3407df2460e1473e35f8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This CVE relates to bad ownership of /var/log/cups, which we don't have.
(From OE-Core rev: 60bca0789b9830fa27694c5d65042d1206a07fe2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've noticed that:
MACHINE=qemuarm oe-selftest -r glibc.GlibcSelfTest.test_glibc
ends up with one process growing to about the size of system memory
and triggering the OOM killer. This has been taking out other builds
running on the system on the autobuilders and is one cause of our
intermittent failures.
This was tracked down to:
WORKDIR=XXX/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/glibc-testsuite/2.33-r0
BUILDDIR=$WORKDIR/build-arm-poky-linux-gnueabi QEMU_SYSROOT=$WORKDIR/recipe-sysroot
QEMU_OPTIONS="$WORKDIR/recipe-sysroot-native/usr/bin/qemu-arm -r 3.2.0" \
$WORKDIR/check-test-wrapper user env GCONV_PATH=$BUILDDIR/iconvdata LOCPATH=$BUILDDIR/localedata LC_ALL=C $BUILDDIR/elf/ld-linux-armhf.so.3 \
--library-path $BUILDDIR:$BUILDDIR/math:$BUILDDIR/elf:$BUILDDIR/dlfcn:$BUILDDIR/nss:$BUILDDIR/nis:$BUILDDIR/rt:$BUILDDIR/resolv:$BUILDDIR/mathvec:$BUILDDIR/support:$BUILDDIR/nptl \
$BUILDDIR/nptl/tst-pthread-timedlock-lockloop
although other glibc tests appear to use 16GB of memory before failing
anyway. By capping the VM size to 8GB, we see the same number of failures
but no OOM situations. There may be some issue in qemu or the test which
could be improved to avoid this entirely but this provides a necessary
and useful safeguard to other builds and doensn't appear to make the
situation worse.
On a loaded system OOM may not occur as the test timeout may be triggered
first. An experiment with a 5GB limit showed an additional 7 failures.
(From OE-Core rev: 0dfbc94bb61095138c3d3ff026b2981f0061c1ca)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This upgrade builds unnative with gcc11 allowing it to work with newer distros
using gcc 11.
(From OE-Core rev: 700c00265f5b85e876b632df787a2e3121aee3a6)
Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issue only affects Debian and SUSE.
(From OE-Core rev: 37ff24c9ba0634e7b69dd9c2219b8fd8b2315de6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some fix upstream addresses the issue, it isn't clear which change this was. Our
current version doesn't have issues with the test image though so we can exclude.
(From OE-Core rev: 65124cac1ac1d0b746eacfe128da19c353f07eb0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These CVEs are fixed with kernel changes and don't affect the bluez recipe.
(From OE-Core rev: 21b6975cc6c785aa3bf7f7d4ea2400e11f1800bd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE is in the jpeg sources included with ghostscript. We use our own
external jpeg library so this doesn't affect us.
(From OE-Core rev: e19caff111bcbd70e5e7507388a4aaea2d10f7e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issue applies to use of cpio in SUSE/OBS, doesn't apply to us.
(From OE-Core rev: a175059e678bf9a5e843d00ac1bbf65b49f97f32)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch mentioned as the fix for the CVE is applied to the 6.0 source
code. Zip versioning makes CPE entry changes hard.
(From OE-Core rev: f816be9387d4691dbacd17673749809fe125d35c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE only applies to some distributed RHEL binaries so irrelavent to us.
(From OE-Core rev: 416230b7236c391e89d0d7941b2d34b6234f993c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't build/use the OPIE PAM module, exclude the CVE from this recipe.
(From OE-Core rev: a7aba0f1226411f44f316cdced6b2b47621d1d3f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These CVEs apply to the way logrotate was installed on Gentoo, Debian
and SUSE, exclude from cve-check as they don't apply to OE.
(From OE-Core rev: 55b53c501e911df04bdff6fca54b11c3e54770c9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE is non-specific and depends on the users of jquery, doesn't
make sense to have this flagged against jquery as there is nothing we can
do about it.
(From OE-Core rev: 6f422e966fdc1e62ff0e48d3382ec246ff8bd998)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The issues were investigated and found not to be an issue therefore
exclude from checks.
(From OE-Core rev: 7c7c3f3dd3bf7dc34f26d931acf562e93c45e807)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE applies to the built-in VNC server but we don't enable this by default.
(From OE-Core rev: 9ac9f2709a45fc7ce5b3b9a1a5e4f2e116ec2bb7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE applies to virglrender before 0.6.0 which we don't have.
(From OE-Core rev: d8df88018fc90b2ff039ef58249f8581d22b1cc6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9b5355375d028577de0b98e05992de6a088cb972)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These CVEs are disputed by upstream and there is no plan to fix/address them. No
other distros are carrying patches for them. There is a patch for 1010025
however it isn't merged upstream and probably carries more risk of other bugs
than not having it.
(From OE-Core rev: e764a689844f19230cbf5f9741635f42f677e333)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen cases where an OOM error causes bitbake server to hang:
9171 02:21:09.127810 Command Completed
Traceback (most recent call last):
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/bin/bitbake-server", line 51, in <module>
bb.server.process.execServer(lockfd, readypipeinfd, lockname, sockname, timeout, xmlrpcinterface)
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/server/process.py", line 550, in execServer
server.run()
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/server/process.py", line 108, in run
ret = self.main()
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/server/process.py", line 242, in main
ready = self.idle_commands(.1, fds)
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/server/process.py", line 370, in idle_commands
bb.event.fire(heartbeat, self.cooker.data)
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/event.py", line 216, in fire
fire_class_handlers(event, d)
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/event.py", line 123, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/home/pokybuild/yocto-worker/qemux86/build/bitbake/lib/bb/event.py", line 93, in execute_handler
ret = handler(event)
File "/home/pokybuild/yocto-worker/qemux86/build/meta/classes/buildstats.bbclass", line 182, in defaultrun_buildstats
write_host_data(os.path.join(bsdir, "host_stats"), e, d, "interval")
File "/home/pokybuild/yocto-worker/qemux86/build/meta/classes/buildstats.bbclass", line 160, in write_host_data
output = subprocess.check_output(c.split(), stderr=subprocess.STDOUT, timeout=limit).decode('utf-8')
File "/usr/lib/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib/python3.6/subprocess.py", line 423, in run
with Popen(*popenargs, **kwargs) as process:
File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.6/subprocess.py", line 1295, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory
We need to wrap the calls in the same high level wrapper as idle function calls
and trigger an exit upon an unhandled exception.
(Bitbake rev: 0c83e98b0b4129e43e05129074fff60b22a9f2eb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Include update to previous releases.
(From yocto-docs rev: eb19a2b5687f11c22c7fc26d3efabbf65adb572e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This currently catches the .clb_blob and .vamrs,rock960.txt, and other
.txt files may come in future upstream releases.
(From OE-Core rev: 68647eccaf817287df17d5a247b3caf7df9f6840)
Signed-off-by: Yann Dirson <yann@blade-group.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e332738a8aae0914c58b40faae8b9d7a82fd6a95)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runtest return an error due to missing expect on the target.
Add expect as runtime dependency.
(From OE-Core rev: 9dc044fdbd20085dfa99fd4a7189763365334ede)
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d9a3a08edc1efcbe7b02e80be98370792d3c6cc2)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Occasionally, the build would fail with:
make[2]: execvp: mkdir: Argument list too long
This turned out to be due to a hacky solution used in the recipe to
modify the Makefile, which resulted in one more $(BUILD_CFLAGS) being
added to the immediately expanded BUILD_CFLAGS Make variable each time
do_configure was executed. After a couple of times, this lead to an
environment with a 140 kB BUILD_CFLAGS when mkdir should execute, which
resulted in the E2BIG.
(From OE-Core rev: 44900610bea76ab8983a899599f78790f6c5f659)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 116e6b61c585c6f0f7ae6f010bd490bb39914348)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the following patches from stable-2.12 branch of lttng repository
to fix errors when building lttng-modules against 5.12+ kernel
since they are not present on the release 2.12.5:
- 17cd2dc9 fix: block: add a disk_uevent helper (v5.12)
- 127135b6 fix backport: block: add a disk_uevent helper (v5.12)
- 853d5903 fix: mm, tracing: kfree event name mismatching with
provider kmem (v5.12)
(From OE-Core rev: 86bcab9e9f4ee5e06f7db8c75d4b983fd2be59d2)
Signed-off-by: Vinicius Aquino <vinicius.aquino@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2538ba2b3490e3599d9ccd637aa8486ea428f1b0)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integrating the following commit(s) to linux-yocto/5.4:
qemuppc32: reduce serial issues seen on shutdown
Richard reported:
We've been seeing a lot of the qemuppc shutdown issue and I decided to
look into it. The really worrying thing looking at the logs locally is the
serial ports are showing irq issues and becoming disabled as nobody would
handle them.
Errors like:
[ 9.194886] irq 36: nobody cared (try booting with the "irqpoll" option)
[ 9.198712] CPU: 0 PID: 127 Comm: bootlogd Not tainted
[ 9.202283] Call Trace:
[ 9.205611] [d1005f00] [c00a0da8] __report_bad_irq+0x50/0x138 (unreliable)
[ 9.209347] [d1005f30] [c00a0cc0] note_interrupt+0x324/0x378
[ 9.212855] [d1005f70] [c009d138] handle_irq_event+0xe8/0x104
[ 9.216353] [d1005fa0] [c00a1d9c] handle_fasteoi_irq+0xc0/0x29c
[ 9.219960] [d1005fc0] [c009b798] generic_handle_irq+0x40/0x5c
[ 9.223496] [d1005fd0] [c00075d0] __do_irq+0x58/0x188
[ 9.226948] [d1005ff0] [c0010040] call_do_irq+0x20/0x38
[ 9.230391] [d29eda60] [c0007788] do_IRQ+0x88/0xfc
[ 9.233860] [d29eda90] [c0016454] ret_from_except+0x0/0x14
[ 9.237288] --- interrupt: 501 at __setup_irq+0x3c4/0x838
[ 9.237288] LR = __setup_irq+0x790/0x838
[ 9.244155] [d29edb88] [c009f0a4] request_threaded_irq+0x114/0x1c8
[ 9.247672] [d29edbb8] [c07a5a18] pmz_startup+0x17c/0x32c
[ 9.251203] [d29edbd8] [c07a1140] uart_port_startup+0x184/0x2f8
[ 9.254651] [d29edc08] [c07a1974] uart_port_activate+0x78/0xf4
[ 9.258141] [d29edc28] [c07839f8] tty_port_open+0xd4/0x170
[ 9.261579] [d29edc58] [c079db74] uart_open+0x2c/0x48
[ 9.265116] [d29edc68] [c077a288] tty_open+0x168/0x640
[ 9.268574] [d29edcd8] [c0280be8] chrdev_open+0x138/0x2a4
[ 9.272123] [d29edd18] [c027421c] do_dentry_open+0x228/0x410
[ 9.275643] [d29edd48] [c028e9f4] path_openat+0xb04/0xf28
[ 9.279184] [d29eddd8] [c02917e4] do_filp_open+0x120/0x164
[ 9.282535] [d29ede98] [c0276238] do_sys_openat2+0xd8/0x19c
[ 9.285790] [d29edee8] [c0276574] sys_openat+0x88/0xdc
[ 9.289096] [d29edf38] [c00160d8] ret_from_syscall+0x0/0x34
[ 9.292620] --- interrupt: c01 at 0xfec3738
[ 9.292620] LR = 0xfec36e0
[ 9.299035] handlers:
[ 9.302312] [<7f7f7da8>] pmz_interrupt
[ 9.305541] Disabling IRQ #36
(and the irqpoll option does not help)
This is problematic as the shutdown test uses the serial interface to
shut down the system. If the serial interface fails to login or run the command,
game over for the test.
CONFIG_SERIAL_PMACZILOG_CONSOLE complicates that handling, but doesn't provide
any output or capabilities that we need. So we disable it here, and
reduce the chances of issues during shutdown.
(From OE-Core rev: aca5873e830d3b66f00cad4fa03982cc4ec5b445)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 42355cb73049ee7a4af0f539a2a5b7d4ee1abc65)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update CVE_PRODUCT to also include 'berkeley_db'. For example,
CVE-2020-2981 uses 'berkeley_db'.
(From OE-Core rev: b5004de05327c734d63cfac153ebf1542f9177c9)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ad799b109716ccd2f44dcf7a6a4cfcbd622ea661)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
