linux/poky.git/meta/recipes-support, branch yocto-3.3.2

curl: Fix CVE-2021-22897

2021-07-20T18:05:45+00:00

CVE: CVE-2021-22897 (From OE-Core rev: 718d6ca70b99fa4bef4c88114c1bd511b6df121e) Signed-off-by: Khairul Rohaizzat Jamaluddin Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

curl: Fix CVE-2021-22898

2021-07-20T18:05:45+00:00

CVE: CVE-2021-22898 (From OE-Core rev: 4d703dd86c6b27790e1e34d3127652657243d20d) Signed-off-by: Khairul Rohaizzat Jamaluddin Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

boost-build-native: workaround one rarely hang problem on fedora34

2021-07-20T18:05:45+00:00

Reproduce scenes: * On fedora34 * autofs.service is started * test is nis user, which mounted at /nis by autofs * under /nis/test, there are symlinks point to another nis mount point /nis/yan Result: task boost-build-native:do_install hang forever NOTE: recipe ovmf-edk2-stable202102-r0: task do_package_write_rpm: Succeeded NOTE: Running noexec task 8124 of 8152 (/layers/oe-core/meta/recipes-core/ovmf/ovmf_git.bb:do_build) Bitbake still alive (5000s) Bitbake still alive (10000s) Bitbake still alive (15000s) Bitbake still alive (20000s) Bitbake still alive (25000s) Bitbake still alive (30000s) Bitbake still alive (35000s) Bitbake still alive (40000s) Bitbake still alive (45000s) Bitbake still alive (50000s) $ps aux | grep b2 test 2773444 0.0 0.0 13532 2748 ? D Jul01 0:00 ./b2 install --prefix=/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/recipe-sysroot-native/usr staging-prefix=/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/image/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/recipe-sysroot-native/usr $ sudo cat /proc/2773444/stack [<0>] autofs_wait+0x257/0x720 [<0>] autofs_mount_wait+0x49/0xf0 [<0>] autofs_d_manage+0x76/0x1a0 [<0>] __traverse_mounts+0xd9/0x220 [<0>] step_into+0x3ad/0x6d0 [<0>] walk_component+0x62/0x190 [<0>] link_path_walk.part.0.constprop.0+0x20d/0x350 [<0>] path_lookupat+0x3a/0x1b0 [<0>] filename_lookup+0x9b/0x180 [<0>] vfs_statx+0x64/0x100 [<0>] __do_sys_newfstatat+0x1e/0x40 [<0>] do_syscall_64+0x33/0x40 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 $ dmesg [1559743.424610] autofs4:pid:2773444:autofs_mount_wait: waiting for mount name=yan [1559743.424621] autofs4:pid:2773444:autofs_wait: existing wait id = 0x00000056, name = yan, nfy=1 [1560001.400440] autofs4:pid:2774530:autofs_mount_wait: waiting for mount name=yan [1560001.400452] autofs4:pid:2774530:autofs_wait: existing wait id = 0x00000056, name = yan, nfy=1 [1560022.493282] autofs4:pid:2774537:autofs_mount_wait: waiting for mount name=yan [1560022.493292] autofs4:pid:2774537:autofs_wait: existing wait id = 0x00000056, name = yan, nfy=1 [1560122.076589] autofs4:pid:3979116:autofs_mount_wait: mount wait done status=-4 [1560162.222374] autofs4:pid:2774530:autofs_mount_wait: mount wait done status=-4 [1560167.116188] autofs4:pid:2774537:autofs_mount_wait: mount wait done status=-4 [1560188.140532] autofs4:pid:2774671:autofs_mount_wait: waiting for mount name=yan [1560188.140540] autofs4:pid:2774671:autofs_wait: existing wait id = 0x00000056, name = yan, nfy=1 [1560189.651905] autofs4:pid:2774671:autofs_mount_wait: mount wait done status=-4 Analyzation: b2 will walk the HOME dir, when access the symlink point to /nis/yan, autofs hang at autofs_wait. the process stay at D stat forever. This maybe caused by abnormal status of autofs.service. The problem cannot reproduce after restart autofs.service. There should be an autofs bug. and there is an autofs hang problem bug on fedora34 on it's bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1953390 Workaround: Since b2 don't actually write something to HOME dir, change HOME dir to /var/run, a dir not mounted by autofs. (From OE-Core rev: 760b7b6a031c9dcc9a44e086e1d2dbb2171b3c97) Signed-off-by: Changqing Li Signed-off-by: Alexandre Belloni (cherry picked from commit 7ff692d2e9787bb5b36929a208597595473db0c7) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

curl: fix build when proxy is not enabled in PACKAGECONFIG

2021-07-06T12:02:30+00:00

Backport upstream patches to fix issues introduced by a backported CVE patch. Fixes: | ../../curl-7.75.0/lib/vtls/vtls.c: In function ‘Curl_ssl_addsessionid’: | ../../curl-7.75.0/lib/vtls/vtls.c:508:14: error: ‘isProxy’ redeclared as different kind of symbol | 508 | const bool isProxy = FALSE; | | ^~~~~~~ | ../../curl-7.75.0/lib/vtls/vtls.c:488:37: note: previous definition of ‘isProxy’ with type ‘_Bool’ | 488 | bool isProxy, | | ^ (From OE-Core rev: e900a44e76dc2bb20ff725f24333c1c2b330bf41) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

libgcrypt: upgrade 1.9.2 -> 1.9.3

2021-07-06T12:02:30+00:00

License-Update: added terms for cipher/cipher-gcm-ppc.c, still under GPL (From OE-Core rev: d28c1f67c447f99313890e68083da61adcc66f74 ) (From OE-Core rev: 8cb77273abd6985242cf45100b2fb732db74e909) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie Signed-off-by: Lee Chee Yang Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

curl: cleanup CVE patches for hardknott

2021-06-26T14:24:08+00:00

The patch backported to address CVE-2021-22890 was missing a bracket to properly close out the logic in lib/vtls/wolfssl.c. Fix this so to avoid any surprise failures when using curl with hardknott. Also fix the CVE designation in the patch descriptions for CVEs CVE-2021-22890 and CVE-2021-22876 so that CVE checks run with bitbake correctly detect that they are patched. (From OE-Core rev: 456ba1717fc3ebb9d10cc6a3c916b07f7c4e8a22) Signed-off-by: Trevor Gamblin Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

curl: fix CVE-2021-22876

2021-06-03T15:31:02+00:00

Backport and modify the patch for CVE-2021-22876 from curl 7.76 to make it apply cleanly on 7.75. CVE: CVE-2021-22876 (From OE-Core rev: 7c39b71b78ffc64a456872769b341cfc662e747d) Signed-off-by: Trevor Gamblin Signed-off-by: Richard Purdie

curl: fix CVE-2021-22890

2021-06-03T15:31:02+00:00

Backport and modify the patch for CVE-2021-22890 from curl 7.76 to make it apply cleanly on 7.75. CVE: CVE-2021-22890 (From OE-Core rev: b11dc35cce0449623182ecf044c4a49664119b9c) Signed-off-by: Trevor Gamblin Signed-off-by: Richard Purdie

boost: fix do_fetch failure

2021-05-30T07:19:35+00:00

Bintray service has been discontinued causing boost do_fetch to fail: WARNING: boost-1.76.0-r0 do_fetch: Failed to fetch URL https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2, attempting MIRRORS if available RP: Backport to 1.75.0 (From OE-Core rev: 146f04f9d38f781767a52884f4870570c0d817e0) Signed-off-by: Stefan Ghinea Signed-off-by: Richard Purdie

libcap: Configure Make variables correctly without a horrible hack

2021-05-15T16:18:21+00:00

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 Signed-off-by: Richard Purdie (cherry picked from commit 116e6b61c585c6f0f7ae6f010bd490bb39914348) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie