public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
From: "WANG Xuerui" <xen0n@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] repo/gentoo:master commit in: sys-fs/erofs-utils/, sys-fs/erofs-utils/files/
Date: Sat, 15 Jul 2023 17:51:45 +0000 (UTC)	[thread overview]
Message-ID: <1689443453.65fec4463485c48cd2a2a2803b9adbd3afb43e10.xen0n@gentoo> (raw)

commit:     65fec4463485c48cd2a2a2803b9adbd3afb43e10
Author:     WANG Xuerui <xen0n <AT> gentoo <DOT> org>
AuthorDate: Sat Jul 15 17:50:16 2023 +0000
Commit:     WANG Xuerui <xen0n <AT> gentoo <DOT> org>
CommitDate: Sat Jul 15 17:50:53 2023 +0000
URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=65fec446

sys-fs/erofs-utils: patch CVE-2023-33551 and CVE-2023-33552 for 1.6

Bug: https://bugs.gentoo.org/907674
Signed-off-by: WANG Xuerui <xen0n <AT> gentoo.org>

 sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild       |  49 +++++++++
 .../files/erofs-utils-1.6-CVE-2023-33551.patch     |  70 ++++++++++++
 .../files/erofs-utils-1.6-CVE-2023-33552.patch     | 117 +++++++++++++++++++++
 3 files changed, 236 insertions(+)

diff --git a/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild b/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild
new file mode 100644
index 000000000000..87fe99420cfd
--- /dev/null
+++ b/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild
@@ -0,0 +1,49 @@
+# Copyright 2021-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit autotools
+
+DESCRIPTION="Userspace tools for EROFS"
+HOMEPAGE="https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git"
+LICENSE="GPL-2+"
+
+SRC_URI="https://git.kernel.org/pub/scm/linux/kernel/git/xiang/${PN}.git/snapshot/${P}.tar.gz"
+KEYWORDS="~amd64 ~loong"
+
+SLOT="0"
+IUSE="fuse +lz4 +lzma selinux +uuid"
+
+RDEPEND="
+	fuse? ( sys-fs/fuse:0 )
+	lz4? ( app-arch/lz4:0= )
+	lzma? ( >=app-arch/xz-utils-5.4.0:0= )
+	selinux? ( sys-libs/libselinux:0= )
+	uuid? ( sys-apps/util-linux )
+"
+DEPEND="${RDEPEND}"
+BDEPEND="virtual/pkgconfig"
+
+PATCHES=(
+	"${FILESDIR}/${P}-CVE-2023-33551.patch"
+	"${FILESDIR}/${P}-CVE-2023-33552.patch"
+)
+
+src_prepare() {
+	default
+	eautoreconf
+}
+
+src_configure() {
+	local myeconfargs=(
+		--disable-werror
+		$(use_enable fuse)
+		$(use_enable lz4)
+		$(use_enable lzma)
+		$(use_with selinux)
+		$(use_with uuid)
+	)
+
+	econf "${myeconfargs[@]}"
+}

diff --git a/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33551.patch b/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33551.patch
new file mode 100644
index 000000000000..ce20d18cb33f
--- /dev/null
+++ b/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33551.patch
@@ -0,0 +1,70 @@
+https://git.kernel.org/xiang/erofs-utils/c/27aeef179bf17d5f1d98f827e93d24839a6d4176
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+Date: Fri, 2 Jun 2023 13:52:56 +0800
+Subject: 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 <lometsj@live.com>
+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 <hsiangkao@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20230602055256.18061-1-hsiangkao@linux.alibaba.com
+--- 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;
+ }
+ 
+-- 
+cgit 
+

diff --git a/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33552.patch b/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33552.patch
new file mode 100644
index 000000000000..c53a9b8044fe
--- /dev/null
+++ b/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33552.patch
@@ -0,0 +1,117 @@
+https://git.kernel.org/xiang/erofs-utils/c/2145dff03dd3f3f74bcda3b52160fbad37f7fcfe
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+Date: Fri, 2 Jun 2023 11:05:19 +0800
+Subject: 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 <lometsj@live.com>
+Fixes: 412c8f908132 ("erofs-utils: fsck: add --extract=X support to extract to path X")
+Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20230602030519.117071-1-hsiangkao@linux.alibaba.com
+--- 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)
+-- 
+cgit 
+


             reply	other threads:[~2023-07-15 17:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 17:51 WANG Xuerui [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-08-13  7:10 [gentoo-commits] repo/gentoo:master commit in: sys-fs/erofs-utils/, sys-fs/erofs-utils/files/ WANG Xuerui
2022-03-18  4:20 Xuerui WANG

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1689443453.65fec4463485c48cd2a2a2803b9adbd3afb43e10.xen0n@gentoo \
    --to=xen0n@gentoo.org \
    --cc=gentoo-commits@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox