From patchwork Wed Nov 1 14:25:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: auh@yoctoproject.org X-Patchwork-Id: 33309 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FFDCC07E98 for ; Wed, 1 Nov 2023 14:25:13 +0000 (UTC) Received: from a27-45.smtp-out.us-west-2.amazonses.com (a27-45.smtp-out.us-west-2.amazonses.com [54.240.27.45]) by mx.groups.io with SMTP id smtpd.web11.8480.1698848703495532161 for ; Wed, 01 Nov 2023 07:25:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@yoctoproject.org header.s=lvjh2tk576v2ro5mi6k4dt3mc6wpqbky header.b=KuMCiwQN; dkim=pass header.i=@amazonses.com header.s=hsbnp7p3ensaochzwyq5wwmceodymuwv header.b=IurkQ5Ut; spf=pass (domain: automation.yoctoproject.org, ip: 54.240.27.45, mailfrom: 0101018b8b4600f1-2e099588-ace2-48c5-aee1-964a85a9ae25-000000@automation.yoctoproject.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=lvjh2tk576v2ro5mi6k4dt3mc6wpqbky; d=yoctoproject.org; t=1698848703; h=Content-Type:MIME-Version:From:To:Subject:Message-Id:Date; bh=JnMskKakd4zxq35dBl4SlRTtiEpisItSvKB3J/xPc2s=; b=KuMCiwQNIMz3YMVciKNvWkapwYgxYe96OAzNXfxF63SLikkuih0AFn/E+UJpOkN1 YqdJajpnlkNmR1hyQ54VbLqGisgBE6D0ZccllYQPzS0LRKcl7ooFJKiZ8yiqiwzMCuf myRZhgSjYNCW9QhnAxtquWfXzp4XZRGcXwYr3G+w= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=hsbnp7p3ensaochzwyq5wwmceodymuwv; d=amazonses.com; t=1698848703; h=Content-Type:MIME-Version:From:To:Subject:Message-Id:Date:Feedback-ID; bh=JnMskKakd4zxq35dBl4SlRTtiEpisItSvKB3J/xPc2s=; b=IurkQ5UtEyMYwoJ72iS4TWq+6j1EiNhm+q6+92pDRbpjZpjU0h1P2rTvoFNP/lJU fNgiZXvLSegNN6iLIkncJVgCqjsaFMUvIHyuH3DuHjDCRxYeUjpH9bI2hb7UcxeoTF0 +vIUYjIm3MsBQwt50iFyMgMDa9gy7guCR7sBL+tI= MIME-Version: 1.0 From: auh@yoctoproject.org To: openembedded-core@lists.openembedded.org Subject: [AUH] erofs-utils: upgrading to 1.7.1 FAILED Message-ID: <0101018b8b4600f1-2e099588-ace2-48c5-aee1-964a85a9ae25-000000@us-west-2.amazonses.com> Date: Wed, 1 Nov 2023 14:25:02 +0000 Feedback-ID: 1.us-west-2.9np3MYPs3fEaOBysGKSlUD4KtcmPijcmS9Az2Hwf7iQ=:AmazonSES X-SES-Outgoing: 2023.11.01-54.240.27.45 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 01 Nov 2023 14:25:13 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/189930 Hello, this email is a notification from the Auto Upgrade Helper that the automatic attempt to upgrade the recipe *erofs-utils* to *1.7.1* has Failed(do_compile). Detailed error information: do_compile failed Next steps: - apply the patch: git am 0001-erofs-utils-upgrade-1.6-1.7.1.patch - check the changes to upstream patches and summarize them in the commit message, - compile an image that contains the package - perform some basic sanity tests - amend the patch and sign it off: git commit -s --reset-author --amend - send it to the appropriate mailing list Alternatively, if you believe the recipe should not be upgraded at this time, you can fill RECIPE_NO_UPDATE_REASON in respective recipe file so that automatic upgrades would no longer be attempted. Please review the attached files for further information and build/update failures. Any problem please file a bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler Regards, The Upgrade Helper -- >8 -- From 77a15a1afc34aa6bad9429079807ffcd28c0cf39 Mon Sep 17 00:00:00 2001 From: Upgrade Helper Date: Wed, 1 Nov 2023 06:50:30 +0000 Subject: [PATCH] erofs-utils: upgrade 1.6 -> 1.7.1 --- ...rofs-utils_1.6.bb => erofs-utils_1.7.1.bb} | 7 +- ...-don-t-allocate-read-too-large-exten.patch | 126 ------------------ ...-block-insane-long-paths-when-extrac.patch | 80 ----------- 3 files changed, 2 insertions(+), 211 deletions(-) rename meta/recipes-devtools/erofs-utils/{erofs-utils_1.6.bb => erofs-utils_1.7.1.bb} (73%) delete mode 100644 meta/recipes-devtools/erofs-utils/files/0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch delete mode 100644 meta/recipes-devtools/erofs-utils/files/0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch diff --git a/meta/recipes-devtools/erofs-utils/erofs-utils_1.6.bb b/meta/recipes-devtools/erofs-utils/erofs-utils_1.7.1.bb similarity index 73% rename from meta/recipes-devtools/erofs-utils/erofs-utils_1.6.bb rename to meta/recipes-devtools/erofs-utils/erofs-utils_1.7.1.bb index 5a89e4b8ee..4c51c84ab2 100644 --- a/meta/recipes-devtools/erofs-utils/erofs-utils_1.6.bb +++ b/meta/recipes-devtools/erofs-utils/erofs-utils_1.7.1.bb @@ -5,11 +5,8 @@ SECTION = "base" LIC_FILES_CHKSUM = "file://COPYING;md5=73001d804ea1e3d84365f652242cca20" HOMEPAGE = "https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/README" -SRCREV = "21710612d35cd952490959bfa6ea9fe87aaa52dd" -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git;branch=master;protocol=https \ - file://0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch \ - file://0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch \ -" +SRCREV = "83d94dc619075e71ca4d0f42941cfc18d269a2af" +SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git;branch=master;protocol=https" UPSTREAM_CHECK_GITTAGREGEX = "v(?P(\d+(\.\d+)+))" diff --git a/meta/recipes-devtools/erofs-utils/files/0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch b/meta/recipes-devtools/erofs-utils/files/0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch deleted file mode 100644 index 52f475dc42..0000000000 --- a/meta/recipes-devtools/erofs-utils/files/0001-erofs-utils-fsck-don-t-allocate-read-too-large-exten.patch +++ /dev/null @@ -1,126 +0,0 @@ -From c769805c79d5acede65d96e5786aa5ebb46c01e0 Mon Sep 17 00:00:00 2001 -From: Gao Xiang -Date: Fri, 2 Jun 2023 11:05:19 +0800 -Subject: [PATCH 1/2] erofs-utils: fsck: don't allocate/read too large extents - -Since some crafted EROFS filesystem images could have insane large -extents, which causes unexpected bahaviors when extracting data. - -Fix it by extracting large extents with a buffer of a reasonable -maximum size limit and reading multiple times instead. - -Note that only `--extract` option is impacted. - -CVE: CVE-2023-33552 -Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-33552 -Reported-by: Chaoming Yang -Fixes: 412c8f908132 ("erofs-utils: fsck: add --extract=X support to extract to path X") -Signed-off-by: Gao Xiang -Link: https://lore.kernel.org/r/20230602030519.117071-1-hsiangkao@linux.alibaba.com - -Upstream-Status: Backport -Signed-off-by: Ross Burton ---- - fsck/main.c | 63 +++++++++++++++++++++++++++++++++++++++++------------ - 1 file changed, 49 insertions(+), 14 deletions(-) - -diff --git a/fsck/main.c b/fsck/main.c -index 6b42252..6689ad8 100644 ---- a/fsck/main.c -+++ b/fsck/main.c -@@ -392,6 +392,8 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd) - } - - while (pos < inode->i_size) { -+ unsigned int alloc_rawsize; -+ - map.m_la = pos; - if (compressed) - ret = z_erofs_map_blocks_iter(inode, &map, -@@ -420,10 +422,28 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd) - if (!(map.m_flags & EROFS_MAP_MAPPED) || !fsckcfg.check_decomp) - continue; - -- if (map.m_plen > raw_size) { -- raw_size = map.m_plen; -- raw = realloc(raw, raw_size); -- BUG_ON(!raw); -+ if (map.m_plen > Z_EROFS_PCLUSTER_MAX_SIZE) { -+ if (compressed) { -+ erofs_err("invalid pcluster size %" PRIu64 " @ offset %" PRIu64 " of nid %" PRIu64, -+ map.m_plen, map.m_la, -+ inode->nid | 0ULL); -+ ret = -EFSCORRUPTED; -+ goto out; -+ } -+ alloc_rawsize = Z_EROFS_PCLUSTER_MAX_SIZE; -+ } else { -+ alloc_rawsize = map.m_plen; -+ } -+ -+ if (alloc_rawsize > raw_size) { -+ char *newraw = realloc(raw, alloc_rawsize); -+ -+ if (!newraw) { -+ ret = -ENOMEM; -+ goto out; -+ } -+ raw = newraw; -+ raw_size = alloc_rawsize; - } - - if (compressed) { -@@ -434,18 +454,27 @@ static int erofs_verify_inode_data(struct erofs_inode *inode, int outfd) - } - ret = z_erofs_read_one_data(inode, &map, raw, buffer, - 0, map.m_llen, false); -+ if (ret) -+ goto out; -+ -+ if (outfd >= 0 && write(outfd, buffer, map.m_llen) < 0) -+ goto fail_eio; - } else { -- ret = erofs_read_one_data(&map, raw, 0, map.m_plen); -- } -- if (ret) -- goto out; -+ u64 p = 0; - -- if (outfd >= 0 && write(outfd, compressed ? buffer : raw, -- map.m_llen) < 0) { -- erofs_err("I/O error occurred when verifying data chunk @ nid %llu", -- inode->nid | 0ULL); -- ret = -EIO; -- goto out; -+ do { -+ u64 count = min_t(u64, alloc_rawsize, -+ map.m_llen); -+ -+ ret = erofs_read_one_data(&map, raw, p, count); -+ if (ret) -+ goto out; -+ -+ if (outfd >= 0 && write(outfd, raw, count) < 0) -+ goto fail_eio; -+ map.m_llen -= count; -+ p += count; -+ } while (map.m_llen); - } - } - -@@ -460,6 +489,12 @@ out: - if (buffer) - free(buffer); - return ret < 0 ? ret : 0; -+ -+fail_eio: -+ erofs_err("I/O error occurred when verifying data chunk @ nid %llu", -+ inode->nid | 0ULL); -+ ret = -EIO; -+ goto out; - } - - static inline int erofs_extract_dir(struct erofs_inode *inode) --- -2.34.1 - diff --git a/meta/recipes-devtools/erofs-utils/files/0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch b/meta/recipes-devtools/erofs-utils/files/0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch deleted file mode 100644 index f2f1e34368..0000000000 --- a/meta/recipes-devtools/erofs-utils/files/0002-erofs-utils-fsck-block-insane-long-paths-when-extrac.patch +++ /dev/null @@ -1,80 +0,0 @@ -From 6cebfbb79b1d5d8feb48801e1008eea5bfa8b599 Mon Sep 17 00:00:00 2001 -From: Gao Xiang -Date: Fri, 2 Jun 2023 13:52:56 +0800 -Subject: [PATCH 2/2] erofs-utils: fsck: block insane long paths when - extracting images - -Since some crafted EROFS filesystem images could have insane deep -hierarchy (or may form directory loops) which triggers the -PATH_MAX-sized path buffer OR stack overflow. - -Actually some crafted images cannot be deemed as real corrupted -images but over-PATH_MAX paths are not something that we'd like to -support for now. - -CVE: CVE-2023-33551 -Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-33551 -Reported-by: Chaoming Yang -Fixes: f44043561491 ("erofs-utils: introduce fsck.erofs") -Fixes: b11f84f593f9 ("erofs-utils: fsck: convert to use erofs_iterate_dir()") -Fixes: 412c8f908132 ("erofs-utils: fsck: add --extract=X support to extract to path X") -Signeo-off-by: Gao Xiang -Link: https://lore.kernel.org/r/20230602055256.18061-1-hsiangkao@linux.alibaba.com - -Upstream-Status: Backport -Signed-off-by: Ross Burton ---- - fsck/main.c | 23 +++++++++++++++-------- - 1 file changed, 15 insertions(+), 8 deletions(-) - -diff --git a/fsck/main.c b/fsck/main.c -index 6689ad8..28d95ec 100644 ---- a/fsck/main.c -+++ b/fsck/main.c -@@ -680,28 +680,35 @@ again: - static int erofsfsck_dirent_iter(struct erofs_dir_context *ctx) - { - int ret; -- size_t prev_pos = fsckcfg.extract_pos; -+ size_t prev_pos, curr_pos; - - if (ctx->dot_dotdot) - return 0; - -- if (fsckcfg.extract_path) { -- size_t curr_pos = prev_pos; -+ prev_pos = fsckcfg.extract_pos; -+ curr_pos = prev_pos; -+ -+ if (prev_pos + ctx->de_namelen >= PATH_MAX) { -+ erofs_err("unable to fsck since the path is too long (%u)", -+ curr_pos + ctx->de_namelen); -+ return -EOPNOTSUPP; -+ } - -+ if (fsckcfg.extract_path) { - fsckcfg.extract_path[curr_pos++] = '/'; - strncpy(fsckcfg.extract_path + curr_pos, ctx->dname, - ctx->de_namelen); - curr_pos += ctx->de_namelen; - fsckcfg.extract_path[curr_pos] = '\0'; -- fsckcfg.extract_pos = curr_pos; -+ } else { -+ curr_pos += ctx->de_namelen; - } -- -+ fsckcfg.extract_pos = curr_pos; - ret = erofsfsck_check_inode(ctx->dir->nid, ctx->de_nid); - -- if (fsckcfg.extract_path) { -+ if (fsckcfg.extract_path) - fsckcfg.extract_path[prev_pos] = '\0'; -- fsckcfg.extract_pos = prev_pos; -- } -+ fsckcfg.extract_pos = prev_pos; - return ret; - } - --- -2.34.1 -