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: Tue, 13 Aug 2024 07:10:25 +0000 (UTC)	[thread overview]
Message-ID: <1723532405.c45494edec51a866382cacb24d5b75810215369b.xen0n@gentoo> (raw)

commit:     c45494edec51a866382cacb24d5b75810215369b
Author:     WANG Xuerui <xen0n <AT> gentoo <DOT> org>
AuthorDate: Tue Aug 13 06:58:33 2024 +0000
Commit:     WANG Xuerui <xen0n <AT> gentoo <DOT> org>
CommitDate: Tue Aug 13 07:00:05 2024 +0000
URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c45494ed

sys-fs/erofs-utils: drop 1.6-r1

Signed-off-by: WANG Xuerui <xen0n <AT> gentoo.org>

 sys-fs/erofs-utils/Manifest                        |   1 -
 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 ---------------------
 4 files changed, 237 deletions(-)

diff --git a/sys-fs/erofs-utils/Manifest b/sys-fs/erofs-utils/Manifest
index 1bf48e6d6a1a..3275e162d261 100644
--- a/sys-fs/erofs-utils/Manifest
+++ b/sys-fs/erofs-utils/Manifest
@@ -1,3 +1,2 @@
-DIST erofs-utils-1.6.tar.gz 126558 BLAKE2B ad4ce3777c484d485b91f29a97c08499398595d654a4ad63e1cc6a75c176b0476d3af1d7a2bf1ef5f6df996281c1b1bdfdf004be4428c0c168652af68acd83d1 SHA512 1537c5cb60cb70c607b8c00408451f90122fe902d80c9d35dde7b9205588ae3513ddd7cb38d4062e55bb57e37d9b53a668752792e6cba0bc0d78176afed3e502
 DIST erofs-utils-1.7.tar.gz 165393 BLAKE2B f22183fbc3346db0632f0fc842586251d0e17ea19e1de3be51cd807dfac4a6150a080d6b81625c3e08eeebc2ae28d7840f8209c905ca87fc70481d3d8c3913ec SHA512 0f204cd40644bde28f9bd0c5c234d93e68db3a3998bb089f43bfb3ce9a9db1e1cc2fa65919205cbd4a484fa4388cffadf5b395bc4363de3882e1a19778c2d62b
 DIST erofs-utils-1.8.1.tar.gz 184385 BLAKE2B 0ecf7ad0d42f3941751511f3ab42e7e25b85dc64849867a221272cf4596f6bfff3cb1c22877a485de79b4445f68eea8e77cb3f8c742a23ee5ad7ce0232b85091 SHA512 b7fe2441e5295680bc683e978ad97ee359785fd842d77fa86ef6bf869b5da87ad613f48782b5f59684995b6cbc5c274938c9ea9067baa537f09c029eabb4cca3

diff --git a/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild b/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild
deleted file mode 100644
index 87fe99420cfd..000000000000
--- a/sys-fs/erofs-utils/erofs-utils-1.6-r1.ebuild
+++ /dev/null
@@ -1,49 +0,0 @@
-# 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
deleted file mode 100644
index ce20d18cb33f..000000000000
--- a/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33551.patch
+++ /dev/null
@@ -1,70 +0,0 @@
-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
deleted file mode 100644
index c53a9b8044fe..000000000000
--- a/sys-fs/erofs-utils/files/erofs-utils-1.6-CVE-2023-33552.patch
+++ /dev/null
@@ -1,117 +0,0 @@
-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:[~2024-08-13  7:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13  7:10 WANG Xuerui [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-07-15 17:51 [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=1723532405.c45494edec51a866382cacb24d5b75810215369b.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